Hi, I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots). When looking at the other property APIs, we have 4 different conventions: 1) CompiledMethod and Behavior: propertyValueAt: 2) RB AST Nodes: propertyAt: 3) Ring: annotationNamed: and (4) Morphic uses: valueOfProperty: I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model. I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch... Marcus
Excellent initiative. In Moose we get propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value So which one do we take? Stef Le 15/8/15 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
On 15 Aug 2015, at 10:46, stepharo <stepharo@free.fr> wrote:
Excellent initiative.
In Moose we get
propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value
Ah, no, this is version (5). I guess #propertyValueNamed: would be number 6).
So which one do we take?
I would use the one that is most close to what we do with #at: The thing is that all these additional words have no meaning. (named, value). Thatâs why everyone uses another one. I think we should have just and API following #at: and #at:put: with âpropertyâ attached to it. Simple, learnable, easy. which is (2). propertyAt:
Stef
Le 15/8/15 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
Hi, I also vote for the xyzAt:put: pattern, even though propertyAt: sounds less English than propertyNamed:. Cheers, Doru On Sat, Aug 15, 2015 at 11:03 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 10:46, stepharo <stepharo@free.fr> wrote:
Excellent initiative.
In Moose we get
propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value
Ah, no, this is version (5). I guess #propertyValueNamed: would be number 6).
So which one do we take?
I would use the one that is most close to what we do with #at:
The thing is that all these additional words have no meaning. (named, value). Thatâs why everyone uses another one.
I think we should have just and API following #at: and #at:put: with âpropertyâ attached to it. Simple, learnable, easy.
which is (2).
propertyAt:
Stef
Le 15/8/15 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
+1. This aligns with Dictionary protocol which these collection of key-value properties essentially are. cheers -ben On Sat, Aug 15, 2015 at 5:08 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I also vote for the xyzAt:put: pattern, even though propertyAt: sounds less English than propertyNamed:.
Cheers, Doru
On Sat, Aug 15, 2015 at 11:03 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 10:46, stepharo <stepharo@free.fr> wrote:
Excellent initiative.
In Moose we get
propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value
Ah, no, this is version (5). I guess #propertyValueNamed: would be number 6).
So which one do we take?
I would use the one that is most close to what we do with #at:
The thing is that all these additional words have no meaning. (named, value). Thatâs why everyone uses another one.
I think we should have just and API following #at: and #at:put: with âpropertyâ attached to it. Simple, learnable, easy.
which is (2).
propertyAt:
Stef
Le 15/8/15 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
On 15 Aug 2015, at 11:40, Ben Coman <btc@openinworld.com> wrote:
+1. This aligns with Dictionary protocol which these collection of key-value properties essentially are. cheers -ben
On Sat, Aug 15, 2015 at 5:08 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I also vote for the xyzAt:put: pattern, even though propertyAt: sounds less English than propertyNamed:.
Cheers, Doru
On Sat, Aug 15, 2015 at 11:03 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 10:46, stepharo <stepharo@free.fr> wrote:
Excellent initiative.
In Moose we get
propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value
Ah, no, this is version (5). I guess #propertyValueNamed: would be number 6).
So which one do we take?
I would use the one that is most close to what we do with #at:
The thing is that all these additional words have no meaning. (named, value). Thatâs why everyone uses another one.
I think we should have just and API following #at: and #at:put: with âpropertyâ attached to it. Simple, learnable, easy.
which is (2).
propertyAt:
Stef
Le 15/8/15 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
On 15 Aug 2015, at 12:56, Marcus Denker <marcus.denker@inria.fr> wrote:
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
Done for Globals and ClassVariables: https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals <https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals> This works for both âClass Variableâ meta objects: (ClassVariableTest classVariableNamed: #TestVariable) propertyAt: #hello put: âyou'. and any Global in the âSmalltalk globalsâ: Object binding propertyAt: #hello put: âyou'. testPropertyAtPut | testValue classVariable | testValue := Date today. classVariable := self class classVariableNamed: #TestVariable. classVariable propertyAt: #testKeySelector put: testValue. self assert: (classVariable propertyAt: #testKeySelector) equals: testValue. TestVariable := 5. "of course changing the var does not change the property" self assert: (classVariable propertyAt: #testKeySelector) equals: testValue. classVariable removeProperty: #testKeySelector. self assert: classVariable properties isNil. Marcus
On 15 Aug 2015, at 16:48, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 12:56, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
Done for Globals and ClassVariables:
https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals <https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals>
in Pharo5 #234. TODO -> properties for Instance Variables -> change #link: to use properties instead of Variable wrappers -> clean up Variable Wrappers (for just adding state) -> implement code generation for MetaLinks on Variables. (same implementation idea as for RB AST Nodes can be used now). Marcus
On 15 Aug 2015, at 18:38, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 16:48, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 15 Aug 2015, at 12:56, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
Done for Globals and ClassVariables:
https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals <https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals>
in Pharo5 #234.
TODO -> properties for Instance Variables
https://pharo.fogbugz.com/f/cases/16224/Property-API-for-Slots <https://pharo.fogbugz.com/f/cases/16224/Property-API-for-Slots> This means that we can now annotate all Instance Variables (Slots) in the system. E.g. (Point slotNamed: #x) propertyAt: #test put: 5 Marcus
Can you give a little example of usecase to illustrate how this will be useful please? :) -- Cyril Le samedi 15 août 2015, Marcus Denker <marcus.denker@inria.fr> a écrit :
On 15 Aug 2015, at 18:38, Marcus Denker <marcus.denker@inria.fr <javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');>> wrote:
On 15 Aug 2015, at 16:48, Marcus Denker <marcus.denker@inria.fr <javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');>> wrote:
On 15 Aug 2015, at 12:56, Marcus Denker <marcus.denker@inria.fr <javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');>> wrote:
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
Done for Globals and ClassVariables:
https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals
in Pharo5 #234.
TODO -> properties for Instance Variables
https://pharo.fogbugz.com/f/cases/16224/Property-API-for-Slots
This means that we can now annotate all Instance Variables (Slots) in the system. E.g.
(Point slotNamed: #x) propertyAt: #test put: 5
Marcus
-- Cheers Cyril Ferlicot
On 15 Aug 2015, at 19:44, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
Can you give a little example of usecase to illustrate how this will be useful please? :)
The reason why I do that now is that I want to be able to put Meta Links on these variables. This means, to âhookâ into all accesses of x in Point, I want to be able to do: metaLink := MetaLink new metaObject: Counter; selector: #inc. (Point slotNamed: #x) link: metaLink. ==> on next call, any method that references the ivar x will be re-compiled just before execution with the Link taken into account. Which means it will insert âCounter incâ before the access. This works, too, on Globals. E.g. you want to #halt next time someone reads the global reference Object? Just do Object binding link: (MetaLink new metaObject: Halt; selector: #now) Lots of possibilities⦠and even for the raw properties I am sure people can find uses. E.g. the Quality assist system actually annotates methods using properties instead of having internal private data structures. It could attach information to *Variables*, too. Maybe other uses are possible, too. Could one store what we statically know about the classes possible of a variable? Marcus
On 15 Aug 2015, at 18:38, Marcus Denker <marcus.denker@inria.fr> wrote:
On 15 Aug 2015, at 16:48, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 15 Aug 2015, at 12:56, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, what I will do first is to add the API to Variables + Packages using the propertyAt: format.
Done for Globals and ClassVariables:
https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals <https://pharo.fogbugz.com/f/cases/16223/Property-API-for-Globals>
in Pharo5 #234.
TODO -> properties for Instance Variables -> change #link: to use properties instead of Variable wrappers -> clean up Variable Wrappers (for just adding state)
This is now all done. Working on:
-> implement code generation for MetaLinks on Variables. (same implementation idea as for RB AST Nodes can be used now).
Marcus
Hoi Tudor--
I also vote for the xyzAt:put: pattern, even though propertyAt: sounds less English than propertyNamed:.
(Obligatory native-English-speaker comment...) I think it maintains continuity with English just as much as "at:" does, which is very much. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Le 15/08/2015 10:24, Marcus Denker a écrit :
Hi,
I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots).
When looking at the other property APIs, we have 4 different conventions:
1) CompiledMethod and Behavior:
propertyValueAt:
2) RB AST Nodes: propertyAt:
3) Ring: annotationNamed:
and (4) Morphic uses: valueOfProperty:
I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model.
I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch...
Marcus
+1 for the propertyAt: / propertyAt:put: / propertyAt:ifPresent:ifAbsent: etc... This is a easiest way, in my opinion, for a relation key/value. We should not touch Morph, but what about bloc ? Bloc seems to use the same names as Morph. -- Cyril
participants (7)
-
Ben Coman -
Craig Latta -
Cyril Ferlicot -
Ferlicot D. Cyril
-
Marcus Denker -
stepharo -
Tudor Girba