Using classes inside Contexts - Restricted OO?

[Andreas Söderlund]

I found some similarities with this recent Dijkstra example from Cope, in a program of mine that uses the Web API HTMLElement as extensively as the "Nameable" class in the Dijkstra example.

It has bothered me that in generics and collections we depart from the visible contract of Roles, to a class that needs to be looked up and grasped, before we can understand the Context properly. I can see the issue with an explicit contract everywhere though:

context Dijkstra {
    public List<{ string name() }> unvisitedNeighborsOf({ string name() } node) {
        List<{ string name() }> allNeighbors = graph_.pathsFrom(node)
        List<{ string name() }> retval = new List<{ string name() }>()
        for ({ string name() } n : allNeighbors) {
            if (unvisiteds_.contains(n)) {
                retval.add(n)
            }
        }
        return retval
    }

    public Dijkstra(NodeGraphInfo graph) {
        graph_ = graph
        tentativeDistances_ = new Map<{ string name() }, int>()
        pathTo = new Map<{ string name() }, { string name() }>()
    }

...which doesn't help the readability of the code at all. So should there be some way to create an alias for a contract in a Context, so Nameable can be looked up and understood directly in the Context, or should we say that well-defined classes/interfaces like those in the standardized Web API should be understood as they are? I wouldn't say that an object with simply a name would fall into that case though, so the question still stands.

/Andreas

[Lund Soltoft]

I’m not sure I understand the problem. Personally I fond F# programs readable but you rarely specify a type for arguments or variables. You only specify the type of the type inference can’t disambiguate. 

So it might be related to habits

Mvh

Rune

Den 2. nov. 2022 kl. 09.20 skrev Andreas Söderlund <gaz...@gmail.com>:

I found some similarities with this recent Dijkstra example from Cope, in a program of mine that uses the Web API HTMLElement as extensively as the "Nameable" class in the Dijkstra example.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/6b147803-decc-4fd7-b1d3-c59268c72f71n%40googlegroups.com.

[Andreas Söderlund]

If a Role must have a (literal) contract, why shouldn't types used within the Context in a Role-like fashion have the same? Would it be ok to define a Role contract as (in a Web API case) HTMLButtonElement | HTMLInputElement ? The compiler could figure out the commonalities and protect from errors, but it's not really about errors here but the locality. Without the literal types that RoleObjectContracts enforce, the programmer has to know how Web API types intersect before fully understanding what's going on in the Context.

/Andreas

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/DDF1AF81-5AC4-451B-A4A4-9DEC4FAF96A4%40gmail.com.

[James O Coplien]

Other than Roles, there probably should be no such types. My 2 cents’ worth…

Sendt fra min iPhone

[Andreas Söderlund]

So Roles should have a literal contract, but other variables/state used within the Context should not? I'm curious to hear your reasoning about when to make things explicit and local, and when not to.

/Andreas

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/0DB5B8DF-1346-4B54-B998-5547C1E0DD32%40gmail.com.

[James O Coplien]

Other than stuff declared on method activation records, I’m puzzled why you conceive other declarations that are not roles

Sendt fra min iPhone

[Andreas Söderlund]

Well, it puzzles me why Role contracts must be literal and explicit, but everything else within the context can be the same old "OO" that we are trying to set right? Especially if everything else comprises the majority of the code.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/CBECD571-9513-46DD-B88B-0653D52B5A5E%40gmail.com.

[James O Coplien]

1. I am not sure if you are talking about DCI or about trygve. DCI is a way of thinking and style of coding and cannot completely be enforced by the language. In any case trygve supports classic abstract data types in addition to DCI. Note that even those contracts (viz., classes and interfaces) are still explicit and literal. Please be explicit yourself in your postulate :-)

One could stipulate that a context contain only roles and a context constructor. But, first, doing so would still not guarantee that the coder created the code with anyy understanding of DCI or with the concomitant code structures. Secondly, doing so would remove a great generalization whereby context objects can themselves be role-players with meaningful instance methods.

2. I am not sure which role contract you mean. A role has an explicit contract to the rest of context (i.e., to other roles and to context instance methods), as well as an explicit contract to role-players.