Den 18/12/2015 kl. 03.21 skrev Andreas <notifi...@github.com>:I was surprised this wasn't allowed? Isn't the outer Context put on hold while the other one executes?
class Person { public Person(String name) { name_ = name; } public String name() const { return name_; } private String name_; } context CleanTable { role Waiter {} requires { String name() const; } // Nice duck typing feature :) public CleanTable(Waiter person) { Waiter = person; } public void clean() { System.out.println(Waiter.name() + " is cleaning the table"); } } context WaitTable { role Waiter { public void waitForGuestsToFinish() { new CleanTable(this).clean(); } } requires { String name() const; } public WaitTable(Person person) { Waiter = person; } public void start() { Waiter.waitForGuestsToFinish(); } } { Person p = new Person("Jeeves"); new WaitTable(p).start(); }
Full output:
___________________________________________________________
Object of type Person playing too many roles, including Waiter
In Context WaitTable: Waiter
In Context CleanTable: Waiter
Jeeves is cleaning the table
--
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 post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.
When would you use a role with no methods, as opposed to a stage prop? A stage prop ensures that the object isn't mutated from within that context, right? I'm guessing that in most cases, the player for a role with most methods wouldn't need to be mutated, so maybe I've answered my own question...I meant to say:
Den 19/12/2015 kl. 15.12 skrev Matthew Browne <mbro...@gmail.com>:
Do you have a version of the money transfer example that doesn't mutate state?
--
Den 19/12/2015 kl. 23.14 skrev Andreas Söderlund <cisc...@gmail.com>:Does that mean the Ledgers collection isn't mutated when something is added to it?
I have a simple mind and fail to grok what you are saying. I have 2 questions.
Consider a bank's Ledger that contains a set of transactions. Transactions can be added but neither changed nor removed.
Question 1: Do you regard this Ledger as immutable? (I say it's changing and, therefore, mutable).
- The balance of an account is computed by selecting and summing over the Ledger transactions.
- A transaction is added to the Ledger
- The balance of the same account is computed by selecting and summing over the Ledger transactions and yield a different result.
More than a billion people own and use computers today. My vision is that a proportion of them will also be programming their computers. This is my target audience. Its members will range from computing novices (most) to experts. Your target audience may be different.
Question 2: Do you mean that the distinction between mutation and addition will help your audience better understand programming?
One way to view this would be to let the program logic be pure functional. There are many advantages to side-effect-free programming, and that’s where I’m headed with trygve in the long term.
Den 20/12/2015 kl. 15.54 skrev Matthew Browne <mbro...@gmail.com>:I like trygve (and Trygve ;) ), but I have to ask: is trygve the best platform for that long-term vision?
I would love to see the trygve project eventually inspire a real language intended for production use. I think our long-term vision, however it evolves, would be best served by eventually ditching Java and class-based syntax entirely, and starting from scratch with a new syntax.
Den 20/12/2015 kl. 15.54 skrev Matthew Browne <mbro...@gmail.com>:
I like trygve (and Trygve ;) ), but I have to ask: is trygve the best platform for that long-term vision?
I would love to see the trygve project eventually inspire a real language intended for production use. I think our long-term vision, however it evolves, would be best served by eventually ditching Java and class-based syntax entirely, and starting from scratch with a new syntax.
To me, trygve is more of a philosophy and a way of exploring the run-time environment than anything else. Your comments remind me of people who call Smalltalk a language. I think it kind of misses then point.
And since you mentioned Javascript, I'll just point out that I don't think Javascript needs classes - a combination of prototypes and DCI contexts could be used instead.
Den 20/12/2015 kl. 15.54 skrev Matthew Browne <mbro...@gmail.com>:
While a more functional model could be an important part of future DCI semantics, do we really want to stretch Java all the way into that territory?
Den 20/12/2015 kl. 16.42 skrev Matthew Browne <mbro...@gmail.com>:Do you envision the trygve environment ultimately being used as a VM for multiple different languages, one or more of which could be suitable for production use?
Den 20/12/2015 kl. 17.32 skrev Matthew Browne <mbro...@gmail.com>:
Another small thing I noticed: it seems that trygve does not allow variable names beginning with an underscore - is that intentional? If we are trying to make this language accessible to Java programmers, then I think allowing at least private property names to begin with underscores is important, and should perhaps even be the default convention. (Yes, I realize that C++ programmers are used to seeing the underscore at the end, so that's an OK convention too, but I think both should be allowed.)
Ok, thanks for the good explanation. I think something to that effect should be included in the documentation, or at least a simple statement that leading underscores are not allowed in variable names (and I'm guessing method names too?).
Sent from my Android phone
--
Den 20/12/2015 kl. 16.42 skrev Matthew Browne <mbro...@gmail.com>:I think prototypes, forwarding, etc. are equally useful concepts that should be considered for support either alongside or as a replacement for classes.
Most importantly, when creating a new language for object-oriented programming, I don't think the presence of classes should be a foregone assumption (I think I just made up that phrase :).
Den 20/12/2015 kl. 16.42 skrev Matthew Browne <mbro...@gmail.com>:
I think prototypes, forwarding, etc. are equally useful concepts that should be considered for support either alongside or as a replacement for classes.
I strongly disagree. As I communicated to the ACCU community, most people who use prototype-based language end creating class-like entities, anyhow: we might as well give them a language that gives expression to that.
And the proper semantics of a classless language are far beyond the ability of most people — even expert programmers — to comprehend. I’ll bet that 90% of the people on this list don’t even know that the Treaty of Orlando exists, let alone what it says (btw, it was just posted to Research Gate after these many years) or are conversant in the seminal work of Stein in this area. She and Smith and Ungar had to get into some really gnarly bits to sort this all out, and the result was the quite elegant aforementioned Treaty.
Understanding proper classless OO where you still want to create loci of encapsulated functions requires a good appreciation of thunk-like behavior, and it’s hard to hide that inside the compiler. And it’s much tougher than Algol-68 thunks because you have both a procedure and data context. (We risk the same thing in DCI, by the way, and I’ll be raising the issue here later. In fact there are two “self” pointers in trygve Role methods: one for the current Role-player (this) and the other for the current Context (current$context). This makes it feasible to, for example, allow unqualified calls to Context superclass methods from methods of its Roles. Is that a good idea? It’s not just an idle concern: the assert facility is defined in class Object, from which all Context and Class instances now inherit. Should one be able to invoke assert from within a Role method, such that the method lookup finds it through current$context? Before you are hasty to answer, remember that other Role names are resolved through current$context already… So a lot of design work remaining to be explored.
Most importantly, when creating a new language for object-oriented programming, I don't think the presence of classes should be a foregone assumption (I think I just made up that phrase :).
I assumed nothing in crafting trygve. Most aspects of its design were carefully considered — otherwise, it would have been done long before this.
Den 20/12/2015 kl. 22.07 skrev Matthew Browne <mbro...@gmail.com>:Speaking of conventions, how about a convention of role names beginning with a lowercase letter?
Den 20/12/2015 kl. 22.15 skrev Matthew Browne <mbro...@gmail.com>:Good point. But should trygve or any new DCI language include all the features of traditional classes, or only some of them? i.e. should it include traditional inheritance, including protected properties, 'super' calls and all the rest from the classes we know and love/hate?
+ Egon
uppercase -> public/large-scope/important; lowercase -> private/small-scope/unimportant.By this rationale I would use uppercase -- roles should stand-out, in the context, from the rest of the line-noise.
I agree with having Roles and Stageprops as uppercase. They are important and should have the attention they deserve! But then what about "this" in a RoleMethod?Replace it with the role name :)
2015-12-20 15:18 GMT+01:00 Trygve Reenskaug <try...@ifi.uio.no>:It seems we have to agree to disagree then.
I have a simple mind and fail to grok what you are saying. I have 2 questions.
Consider a bank's Ledger that contains a set of transactions. Transactions can be added but neither changed nor removed.
Question 1: Do you regard this Ledger as immutable? (I say it's changing and, therefore, mutable).
- The balance of an account is computed by selecting and summing over the Ledger transactions.
- A transaction is added to the Ledger
- The balance of the same account is computed by selecting and summing over the Ledger transactions and yield a different result.
No I would regard each ledger as a snapshot in time. Each of which would be immutable
Den 20/12/2015 kl. 15.54 skrev Matthew Browne <mbro...@gmail.com>:
I like trygve (and Trygve ;) ), but I have to ask: is trygve the best platform for that long-term vision?
I would love to see the trygve project eventually inspire a real language intended for production use. I think our long-term vision, however it evolves, would be best served by eventually ditching Java and class-based syntax entirely, and starting from scratch with a new syntax.
To me, trygve is more of a philosophy and a way of exploring the run-time environment than anything else. Your comments remind me of people who call Smalltalk a language. I think it kind of misses then point.
Den 21/12/2015 kl. 10.55 skrev Trygve Reenskaug <try...@ifi.uio.no>:our focus is on the Model of a program
Den 21/12/2015 kl. 11.00 skrev Egon Elbre <egon...@gmail.com>:When you have two books, same print, same content... would you call it one book?
Den 21/12/2015 kl. 11.12 skrev James O Coplien <jcop...@gmail.com>:Warning: This is just one mental model. There may be others. But I think this mental model is faithful to banking norms, culture, and history, while the “mutable log” model is more a CS perspective. I have been trying to train myself to suppress the latter. Sometimes it leads to some powerful insights from other parts of CS, which is the case here. And, of course, one can reduce the immutable, recursive data model to an iterative, stateful data model – just the opposite of what I did with the factorial example I posted here a couple of days ago.
Den 20/12/2015 kl. 15.54 skrev Matthew Browne <mbro...@gmail.com>:
While a more functional model could be an important part of future DCI semantics, do we really want to stretch Java all the way into that territory?
As it turns out, it’s already there. Most the of the semantics haven’t been debugged yet, but it’s all in the design and initial coding is all done.
the addition of a new Transaction implies creating a new Ledger that includes the new Transaction and then moving all the Transactions from the old to the new Ledger. Some of the references to the old Ledger will have to be updated, making these references mutable.
class Ledger {
private Ledger past_;
private LedgerEntry head_;
private Ledger (LedgerEntry entry, Ledger past) { past_ = past;
head_ = entry;
}public static Empty(){ return empty_;}public Add(LedgerEntry entry){return new Ledger(entry, this);}}
I have suggested that we distinguish role names with ALLCAPS.
That somewhere is what I call the Ledger. It's already stored. It's not unrelated to the the Transactions, it has links to all of them (it's their container). And, as you, say it's mutable.
Den 21/12/2015 kl. 17.05 skrev Matthew Browne <mbro...@gmail.com>:that role names could be easily highlighted in an IDE.
If you were not constrained by the context having its role players rebound but instead it could yield a new context as the result. How would you solve it?
On 12/21/15 4:33 AM, Trygve Reenskaug wrote:
I have suggested that we distinguish role names with ALLCAPS.All caps is my least preferred option. I usually have only used all caps for constants.
I know it's trivial, but I find it inconvenient to switch to caps lock and I don't see any significant advantage of using all caps for role names.
I also doubt that this is a convention that all or most programmers would follow...it's just not a style people are used to these days.
I suppose one could do it like this:
public void transfer() {
Account newSrc = Source.withdraw();
Account newDst = Destination.deposit();
return new TransferMoney(newSrc, newSrc, Amount);
}
...So now that you mention it, it is possible. But I don't see how that makes the code easier to reason about.
I suppose one could do it like this:
public void transfer() {
Account newSrc = Source.withdraw();
Account newDst = Destination.deposit();
return new TransferMoney(newSrc, newSrc, Amount);
}
...So now that you mention it, it is possible. But I don't see how that makes the code easier to reason about.
I see little reason why you would want a context for transferring the same amount between the same accounts once again. Which was my second point. Why is the reference to the current important when the execution is done?
Den 23/12/2015 kl. 01.40 skrev Matthew Browne <mbro...@gmail.com>:I think this is one reason why it's helpful if roles are allowed in top-level functions, without the requirement of creating a stateful Context object. Like in our Javascript implementations:
I think that's surprising given the way the above code is written.
What if you could omit the 'new' keyword and it would run the constructor and automatically destroy the Context instance after it finished executing? So for a Context with a single trigger method, you could do:
TransferMoney(source, dest, 10.0);
instead of:
var transfer = new TransferMoney(source, dest, 10.0);
transfer.run();
So the public TransferMoney method in the TransferMoney context would now have a dual meaning; it would be a constructor if called with new, and otherwise would be the default method that runs when you invoke the Context itself. It could also return a value, e.g.:
int returnValue = MyContext();
The thing I like about doing it this way is that there's still just one kind of declaration for Contexts -- context. One thing that bugs me just a bit about my TypeScript implementation (and upcoming JS source transformation implementation...more on that soon) is that there are two ways of declaring Contexts - the context keyword and the function keyword. In any case it would be nice to have the word 'context' included somewhere when declaring both kinds of Context.
So yeah, add it to the wish list :)
Den 22/12/2015 kl. 17.14 skrev Matthew Browne <mbro...@gmail.com>:...So now that you mention it, it is possible. But I don't see how that makes the code easier to reason about.