Quantcast

about propertyAt: and others

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

about propertyAt: and others

stepharong
Hi

I'm looking at cocoon and other property systems. I would like to get a  
nice library once for all.
I want to also revisit Artefact stylesheets.

I'm checking the semantics regarding the lookup of a property in a parent  
when it is not found in the receiver.

I have the impression that when there is a parent access and modification  
should modify the same object: i.e., the parent if the key is found in the  
parent or the child if the property is found in the child.


in cocoon we have a mix of the two semantics and I would like to get your  
feel about it.

propertyAt: aKey
        "Answer the value of the property ==aKey==, raises an error if the  
property doesn't exist."

        ^ self propertyAt: aKey ifAbsent: [
                self hasParent
                        ifTrue: [ self parent propertyAt: aKey ]
                        ifFalse: [self errorPropertyNotFound: aKey ]]

propertyAt: aKey default: aBlock
        "Answer the value of ==aKey==. If the key have no entry I look on the  
parent or execute a block if i'm an orphan."

        ^ self
                propertyAt: aKey
                ifAbsent: [
                        self hasParent
                                ifTrue: [ self parent propertyAt: aKey default: aBlock ]
                                ifFalse: aBlock ]

but

propertyAt: aKey ifAbsent: aBlock
        "Answer the value of the property ==aKey==, or the result of ==aBlock==  
if the property doesn't exist."

        ^ self properties at: aKey ifAbsent: aBlock

propertyAt: aKey ifAbsentPut: aBlock
        "Answer the value of the property ==aKey==, or if the property doesn't  
exist adds and answers the result of evaluating ==aBlock==."

        ^ self properties at: aKey ifAbsentPut: aBlock



In PetitParser there is no lookup. But we can get back to this situation  
by just not setting a parent.
My gut feeling is telling me that overriding on write is not really good  
because
a client of the parent will not see the changes coming from a child.


I thaought that stylesheet was supporting lookup but it does not

testSubstyleAttributesOverride
        styleSheet at: #textColor put: #red.
        styleSheet > #sub > #subsub at: #textColor put: #blue.
        self assert:( styleSheet get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub > #subsub get: #textColor ) equals: #blue.
Does not work


What you think?

Stef

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about propertyAt: and others

philippeback
What is Cocoon?

Phil

Virus-free. www.avast.com

On Sat, Mar 18, 2017 at 1:18 PM, stepharong <[hidden email]> wrote:
Hi

I'm looking at cocoon and other property systems. I would like to get a nice library once for all.
I want to also revisit Artefact stylesheets.

I'm checking the semantics regarding the lookup of a property in a parent when it is not found in the receiver.

I have the impression that when there is a parent access and modification should modify the same object: i.e., the parent if the key is found in the parent or the child if the property is found in the child.


in cocoon we have a mix of the two semantics and I would like to get your feel about it.

propertyAt: aKey
        "Answer the value of the property ==aKey==, raises an error if the property doesn't exist."

        ^ self propertyAt: aKey ifAbsent: [
                self hasParent
                        ifTrue: [ self parent propertyAt: aKey ]
                        ifFalse: [self errorPropertyNotFound: aKey ]]

propertyAt: aKey default: aBlock
        "Answer the value of ==aKey==. If the key have no entry I look on the parent or execute a block if i'm an orphan."

        ^ self
                propertyAt: aKey
                ifAbsent: [
                        self hasParent
                                ifTrue: [ self parent propertyAt: aKey default: aBlock ]
                                ifFalse: aBlock ]

but

propertyAt: aKey ifAbsent: aBlock
        "Answer the value of the property ==aKey==, or the result of ==aBlock== if the property doesn't exist."

        ^ self properties at: aKey ifAbsent: aBlock

propertyAt: aKey ifAbsentPut: aBlock
        "Answer the value of the property ==aKey==, or if the property doesn't exist adds and answers the result of evaluating ==aBlock==."

        ^ self properties at: aKey ifAbsentPut: aBlock



In PetitParser there is no lookup. But we can get back to this situation by just not setting a parent.
My gut feeling is telling me that overriding on write is not really good because
a client of the parent will not see the changes coming from a child.


I thaought that stylesheet was supporting lookup but it does not

testSubstyleAttributesOverride
        styleSheet at: #textColor put: #red.
        styleSheet > #sub > #subsub at: #textColor put: #blue.
        self assert:( styleSheet get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub > #subsub get: #textColor ) equals: #blue.
Does not work


What you think?

Stef


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: about propertyAt: and others

Stephane Ducasse-3
It is a lib to manage configuration like the one on pillar. 
Now cocoon is using magritte and this is a bit too much for my taste so I'm doing one iteration to produce a new lib where
validation and runtime can be separated. 

Stef

On Sat, Mar 18, 2017 at 3:44 PM, [hidden email] <[hidden email]> wrote:
What is Cocoon?

Phil

Virus-free. www.avast.com

On Sat, Mar 18, 2017 at 1:18 PM, stepharong <[hidden email]> wrote:
Hi

I'm looking at cocoon and other property systems. I would like to get a nice library once for all.
I want to also revisit Artefact stylesheets.

I'm checking the semantics regarding the lookup of a property in a parent when it is not found in the receiver.

I have the impression that when there is a parent access and modification should modify the same object: i.e., the parent if the key is found in the parent or the child if the property is found in the child.


in cocoon we have a mix of the two semantics and I would like to get your feel about it.

propertyAt: aKey
        "Answer the value of the property ==aKey==, raises an error if the property doesn't exist."

        ^ self propertyAt: aKey ifAbsent: [
                self hasParent
                        ifTrue: [ self parent propertyAt: aKey ]
                        ifFalse: [self errorPropertyNotFound: aKey ]]

propertyAt: aKey default: aBlock
        "Answer the value of ==aKey==. If the key have no entry I look on the parent or execute a block if i'm an orphan."

        ^ self
                propertyAt: aKey
                ifAbsent: [
                        self hasParent
                                ifTrue: [ self parent propertyAt: aKey default: aBlock ]
                                ifFalse: aBlock ]

but

propertyAt: aKey ifAbsent: aBlock
        "Answer the value of the property ==aKey==, or the result of ==aBlock== if the property doesn't exist."

        ^ self properties at: aKey ifAbsent: aBlock

propertyAt: aKey ifAbsentPut: aBlock
        "Answer the value of the property ==aKey==, or if the property doesn't exist adds and answers the result of evaluating ==aBlock==."

        ^ self properties at: aKey ifAbsentPut: aBlock



In PetitParser there is no lookup. But we can get back to this situation by just not setting a parent.
My gut feeling is telling me that overriding on write is not really good because
a client of the parent will not see the changes coming from a child.


I thaought that stylesheet was supporting lookup but it does not

testSubstyleAttributesOverride
        styleSheet at: #textColor put: #red.
        styleSheet > #sub > #subsub at: #textColor put: #blue.
        self assert:( styleSheet get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub get: #textColor ) equals: #red.
        self assert:( styleSheet > #sub > #subsub get: #textColor ) equals: #blue.
Does not work


What you think?

Stef



Loading...