Smalltalk › Pharo › Pharo Smalltalk Developers

Unified property API for code.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Marcus Denker-4

Unified property API for code.

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

stepharo

Re: Unified property API for code.

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
>

Marcus Denker-4

Re: Unified property API for code.

> On 15 Aug 2015, at 10:46, stepharo <[hidden email]> 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
>>
>
>

Tudor Girba-2

Re: Unified property API for code.

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 <[hidden email]> wrote:

> On 15 Aug 2015, at 10:46, stepharo <[hidden email]> 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"

Ben Coman

Re: Unified property API for code.

+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 <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>>
>> > On 15 Aug 2015, at 10:46, stepharo <[hidden email]> 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"

Marcus Denker-4

Re: Unified property API for code.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>>
>>>
>>>> On 15 Aug 2015, at 10:46, stepharo <[hidden email]> 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"
>

ccrraaiigg

Re: Unified property API for code.

In reply to this post by Tudor Girba-2

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)

CyrilFerlicot

Re: Unified property API for code.

In reply to this post by Marcus Denker-4

Le 15/08/2015 10:24, Marcus Denker a écrit :

+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

signature.asc (836 bytes) Download Attachment

Marcus Denker-4

Re: Unified property API for code.

>
>
> +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.
>

Then we should fix Bloc.

Marcus

Marcus Denker-4

Re: Unified property API for code.

In reply to this post by Marcus Denker-4

On 15 Aug 2015, at 12:56, Marcus Denker <[hidden email]> 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

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

Marcus Denker-4

Re: Unified property API for code.

On 15 Aug 2015, at 16:48, Marcus Denker <[hidden email]> wrote:

On 15 Aug 2015, at 12:56, Marcus Denker <[hidden email]> 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

-> 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

Marcus Denker-4

Re: Unified property API for code.

On 15 Aug 2015, at 18:38, Marcus Denker <[hidden email]> wrote:

On 15 Aug 2015, at 16:48, Marcus Denker <[hidden email]> wrote:

On 15 Aug 2015, at 12:56, Marcus Denker <[hidden email]> 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

CyrilFerlicot

Re: Unified property API for code.

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 <[hidden email]> a écrit :

On 15 Aug 2015, at 18:38, Marcus Denker <<a href="javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');" target="_blank">marcus.denker@...> wrote:

On 15 Aug 2015, at 16:48, Marcus Denker <<a href="javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');" target="_blank">marcus.denker@...> wrote:

On 15 Aug 2015, at 12:56, Marcus Denker <<a href="javascript:_e(%7B%7D,'cvml','marcus.denker@inria.fr');" target="_blank">marcus.denker@...> 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

Marcus Denker-4

Re: Unified property API for code.

> On 15 Aug 2015, at 19:44, Cyril Ferlicot <[hidden email]> 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

Marcus Denker-4

Re: Unified property API for code.

In reply to this post by Marcus Denker-4

On 15 Aug 2015, at 18:38, Marcus Denker <[hidden email]> wrote:

On 15 Aug 2015, at 16:48, Marcus Denker <[hidden email]> wrote:

On 15 Aug 2015, at 12:56, Marcus Denker <[hidden email]> 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
-> 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