interactive method definition (was Re: Calypso wishlist)
On 9 February 2018 at 03:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Then you might have used kind of named block params like MyClass >> [foo:aFoo bar:aBar | self foo: aFoo; bar: aBar]
Le 8 févr. 2018 20:11, "Stephane Ducasse" <stepharo.self@gmail.com> a écrit :
Hi ben
This is not what I asked for :). In nautilus you do not have to switch mode to define a method.
Ahh, cool. I change the subject.
Now about your proposal. I would like to be able the type tonel method definition
SomeClass >> echo: anObject [ ^ 42 ]
Tonel represents what I want for methods.
Is this your ideal, or mainly to align with Tonel? Because it seems Tonel was developed without much consideration of interactive method definition -- which is fine in as much as Tonel was designed to quickly overcome a specific problem with Windows+Git, but it Tonel shouldn't be set in stone since its introduction changes the environment and stimulates further thinking on requirements. Amongst your many priorities, could you ask someone familiar with changing compiler syntax have a serious look at implementing both ways: 1. Tonel syntax for interactive method definition 2. Named block parameters for interactive method definition to determine practically which one is preferred and easier to support. And feed that into determining whether syntax should adapt to Tonel or whether Tonel should adapt to the latter. It would be better to do this earlier while Tonel is young before it becomes more widely used by other dialects. Also btw, would having named block parameters possibly unify more methods and blocks? (only a random thought, I'm not familiar with the low level distinction) cheers -ben P.S. should Tonel include a format-version field on the first line? Its seems a good practice even if the format never does change for a long time.
This way students could just type nearly as in the books and I would
change the book to reflect this. And people can decide either to type all the time the class or not.
Stef
On Thu, Feb 8, 2018 at 6:28 PM, Ben Coman <btc@openinworld.com> wrote:
On 9 February 2018 at 00:45, Ben Coman <btc@openinworld.com> wrote:
On 8 February 2018 at 16:22, Stephane Ducasse <stepharo.self@gmail.com
wrote:
Hi denis
- I would like to be able to define a method even in the class pane and that the system detects it automatically.
It would be nice to do it from anywhere including Playground with something like... Classname >> #methodname >> [ method source here ]
So I just tired a quick experiment...
Object subclass: #SomeClass instanceVariableNames: '' classVariableNames: '' package: 'MethodBuilderExperiment'
On SomeClass defined method... existingMethod ^1
On CompiledMethod defined method... >> blockClosure | newSource | newSource := self methodNode selector, String crlf, blockClosure sourceNode newSource allButFirst allButLast. self methodClass compile: newSource
Now each of the following lines can be evaluated...
SomeClass existingMethod "==> 1" SomeClass >> #existingMethod >> [ ^42]. SomeClass existingMethod "==> 42"
That should have been.
SomeClass new existingMethod "==> 1" SomeClass >> #existingMethod >> [ ^42]. SomeClass new existingMethod "==> 42"
And another experiment...
Object subclass: #MethodBuilder instanceVariableNames: 'methodClass methodSelector' classVariableNames: '' package: 'MethodBuilderExperiment'
On MethodBuilder defined method... class: aClass selector: aSelector methodClass := aClass. methodSelector := aSelector.
On MethodBuilder defined method... >> blockClosure |newSource| newSource := methodSelector, String crlf, blockClosure sourceNode newSource allButFirst allButLast. methodClass compile: newSource
On Behaviour re-defined method... compiledMethodAt: selector ^ self methodDict at: selector ifAbsent: [ MethodBuilder new class: self selector:
selector ]
Now each of the following lines can be evaluated...
Someclass noMethod "==> error... Instance of SomeClass class did not understand #noMethod" SomeClass >> #noMethod >> [ ^42 ]. Someclass noMethod "==> 42"
And should have been... Someclass new noMethod "==> error... Instance of SomeClass class did not understand #noMethod" SomeClass >> #noMethod >> [ ^42 ]. Someclass new noMethod "==> 42"
I see that is a bit problematic for keyword messages, but with a tweak...
On MethodBuilder defined...
blockClosure |newSource| methodSelector isArray ifFalse: [ newSource := methodSelector ] ifTrue: [ newSource := ''. methodSelector do: [ :token | newSource := newSource , token asString, ' ' ] ]. newSource := newSource, String crlf, blockClosure sourceNode newSource allButFirst allButLast. methodClass compile: newSource
now the following can be evaluated...
SomeClass >>#(echo: anObject) >> [ ^anObject ]. SomeClass new echo: 'doyoulike'. "==> doyoulike"
Another form to define a method might be... SomeClass >> [ echo: anObject ^anObject ]
I think that looks better, but would require a loosening of block syntax.
cheers -ben
- Then we are starting to reverse engineering the ecompletion system and I'm learning it. I would like to know if Calypso can communicate with ecompletion the fact that we are defining a method. Then I have to check how the system can know that we are typing method argument when defining the signature but I think that this is not related to calypso.
Stef
Is this your ideal, or mainly to align with Tonel? Because it seems Tonel was developed without much consideration of interactive method definition -- which is fine in as much as Tonel was designed to quickly overcome a specific problem with Windows+Git, but it Tonel shouldn't be set in stone since its introduction changes the environment and stimulates further thinking on requirements.
Not only. We decided that the methods syntax in tonel could be used in browser and in email. I have this proposal since before ESUG in lugano (2005) so I really thought about it a lot. This is not by accident that the code in all my book follow nearly this shape. The tonel structure is nice because it mimics also other languages. fooSignature { }
Amongst your many priorities, could you ask someone familiar with changing compiler syntax have a serious look at implementing both ways: 1. Tonel syntax for interactive method definition
Yes but we are really busy And yes we want this. So we should do it.
2. Named block parameters for interactive method definition
2 mega sucks. And we will not do it. Sorry.
to determine practically which one is preferred and easier to support.
I will veto 2. And I will be really strong on it. I'm teaching Pharo and this is enough.
And feed that into determining whether syntax should adapt to Tonel or whether Tonel should adapt to the latter. It would be better to do this earlier while Tonel is young before it becomes more widely used by other dialects.
Tonel method definition will not change.
Also btw, would having named block parameters possibly unify more methods and blocks? (only a random thought, I'm not familiar with the low level distinction)
This is not because they look the same that in the conceptual model they should. Now I would like to have optional parameter value (but it can be a bit touchy since there are many design decision to take and it impacts senders and the rest.
cheers -ben
P.S. should Tonel include a format-version field on the first line? Its seems a good practice even if the format never does change for a long time.
Tonel has a property file that encodes metadata.
In fact I'm stupid because I already coded it by extending the parser and I lost the code. I should look around or redo it. On Sat, Feb 10, 2018 at 7:10 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Is this your ideal, or mainly to align with Tonel? Because it seems Tonel was developed without much consideration of interactive method definition -- which is fine in as much as Tonel was designed to quickly overcome a specific problem with Windows+Git, but it Tonel shouldn't be set in stone since its introduction changes the environment and stimulates further thinking on requirements.
Not only. We decided that the methods syntax in tonel could be used in browser and in email. I have this proposal since before ESUG in lugano (2005) so I really thought about it a lot. This is not by accident that the code in all my book follow nearly this shape. The tonel structure is nice because it mimics also other languages.
fooSignature {
}
Amongst your many priorities, could you ask someone familiar with changing compiler syntax have a serious look at implementing both ways: 1. Tonel syntax for interactive method definition
Yes but we are really busy And yes we want this. So we should do it.
2. Named block parameters for interactive method definition
2 mega sucks. And we will not do it. Sorry.
to determine practically which one is preferred and easier to support.
I will veto 2. And I will be really strong on it. I'm teaching Pharo and this is enough.
And feed that into determining whether syntax should adapt to Tonel or whether Tonel should adapt to the latter. It would be better to do this earlier while Tonel is young before it becomes more widely used by other dialects.
Tonel method definition will not change.
Also btw, would having named block parameters possibly unify more methods and blocks? (only a random thought, I'm not familiar with the low level distinction)
This is not because they look the same that in the conceptual model they should. Now I would like to have optional parameter value (but it can be a bit touchy since there are many design decision to take and it impacts senders and the rest.
cheers -ben
P.S. should Tonel include a format-version field on the first line? Its seems a good practice even if the format never does change for a long time.
Tonel has a property file that encodes metadata.
participants (2)
-
Ben Coman -
Stephane Ducasse