Unified property API for code.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Unified property API for code.

Marcus Denker-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

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


Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4

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


Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Tudor Girba-2
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
>>
>
>





--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Ben Coman
+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"

Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4
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"
>


Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

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


Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

CyrilFerlicot
In reply to this post by Marcus Denker-4
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


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4
>
>
> +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


Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4
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:



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
Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4

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:




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

Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

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:




in Pharo5 #234.

TODO
-> properties for Instance Variables


This means that we can now annotate all Instance Variables (Slots) in the system. E.g.


(Point slotNamed: #x) propertyAt: #test put: 5


Marcus

Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

CyrilFerlicot
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,&#39;cvml&#39;,&#39;marcus.denker@inria.fr&#39;);" target="_blank">marcus.denker@...> wrote:


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


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




in Pharo5 #234.

TODO
-> properties for Instance Variables


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

Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Unified property API for code.

Marcus Denker-4
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:




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