Poll: Silk - what is best Smalltalkish way to add namespaced attribute?

> Hello,
>
> The alternative web / DOM library Silk that is being developed at
> herby/silk, has some API choice.
>
> So far, classical attributes can be added like this (adding <p> with
> attributes and content to end of body):
>
> Silk new
> P: { 'id' -> 'theId'. 'class' -> 'blue'. 'The content' }
>
> or
>
> Silk new P
> << ('id' -> 'theId')
> << ('class' -> 'blue')
> << 'The content'.
>
> For namespaced attributes, though, one needs to use namespace, which is
> an url string, and the attribute name, so the key is a tuple. Also, it
> is good to retain the Association as a way to add these attributes. The
> question then is, what to use as a key?
>
>
> 1. Association
>
> Silk new
> P: { ns1 -> 'attr1' -> 'theId'. ns2 -> 'attr2' -> 'blue'. 'The content' }
>
> or
>
> Silk new P
> << ( ns1 -> 'attr1' -> 'theId')
> << ( ns2 -> 'attr2' -> 'blue')
> << 'The content'.
>
> Pros: Easy to write.
> Cons: Slight WTF for beginners (implicit parenthesizing).
>        Conceptually, ns/name tuple is not a key/value pair.
>
>
>
> 2. Array
>
> Silk new
> P: { {ns1. 'attr1'} -> 'theId'. {ns2. 'attr2'} -> 'blue'. 'The content' }
>
> or
>
> Silk new P
> << ( {ns1. 'attr1'} -> 'theId')
> << ( {ns2. 'attr2'} -> 'blue')
> << 'The content'.
>
> Pros: Conceptually nearer to tuple.
> Cons: Maybe a bit growlixy.
>
>
>
> 3. Keyword message
>
> Silk new
> P: { ('attr1' attrNS: ns1) -> 'theId'. ('attr2' attrNS: ns2) -> 'blue'.
> 'The content' }
>
> or
>
> Silk new P
> << ( ('attr1' attrNS: ns1) -> 'theId')
> << ( ('attr2' attrNS: ns2) -> 'blue')
> << 'The content'.
>
> Pros: Conceptually clean.
>        Dedicated class can be used.
> Cons: Hard to write.
>
>
>
> 4. Different binary message than ->
>
> Silk new
> P: { ns1 @ 'attr1' -> 'theId'. ns2 @ 'attr2' -> 'blue'. 'The content' }
>
> or
>
> Silk new P
> << ( ns1 @ 'attr1' -> 'theId')
> << ( ns2 @ 'attr2' -> 'blue')
> << 'The content'.
>
> Pros: Easy to write.
> Cons: Maybe slightly growlixy.
>        In case of @, Point is abused, though other message may create
> dedicated class.
>
>
>
> Could you pick up which version would you see as most clean and
> Smalltalk nature?
>
> Thanks, Herby
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>

>         << 'The content'.
>
> Pros: Classical easy to read Smalltalk style
> Cons: Maybe a bit more effort to implement
>
> On 3/9/15, Herby Vojčík <[hidden email]> wrote:
> > Hello,
> >
> > The alternative web / DOM library Silk that is being developed at
> > herby/silk, has some API choice.
> >
> > So far, classical attributes can be added like this (adding <p> with
> > attributes and content to end of body):
> >
> > Silk new
> > P: { 'id' -> 'theId'. 'class' -> 'blue'. 'The content' }
> >
> > or
> >
> > Silk new P
> > << ('id' -> 'theId')
> > << ('class' -> 'blue')
> > << 'The content'.
> >
> > For namespaced attributes, though, one needs to use namespace, which
> is
> > an url string, and the attribute name, so the key is a tuple. Also,
> it
> > is good to retain the Association as a way to add these attributes.
> The
> > question then is, what to use as a key?
> >
> >
> > 1. Association
> >
> > Silk new
> > P: { ns1 -> 'attr1' -> 'theId'. ns2 -> 'attr2' -> 'blue'. 'The
> content' }
> >
> > or
> >
> > Silk new P
> > << ( ns1 -> 'attr1' -> 'theId')
> > << ( ns2 -> 'attr2' -> 'blue')
> > << 'The content'.
> >
> > Pros: Easy to write.
> > Cons: Slight WTF for beginners (implicit parenthesizing).
> >        Conceptually, ns/name tuple is not a key/value pair.
> >
> >
> >
> > 2. Array
> >
> > Silk new
> > P: { {ns1. 'attr1'} -> 'theId'. {ns2. 'attr2'} -> 'blue'. 'The
> content' }
> >
> > or
> >
> > Silk new P
> > << ( {ns1. 'attr1'} -> 'theId')
> > << ( {ns2. 'attr2'} -> 'blue')
> > << 'The content'.
> >
> > Pros: Conceptually nearer to tuple.
> > Cons: Maybe a bit growlixy.
> >
> >
> >
> > 3. Keyword message
> >
> > Silk new
> > P: { ('attr1' attrNS: ns1) -> 'theId'. ('attr2' attrNS: ns2) ->
> 'blue'.
> > 'The content' }
> >
> > or
> >
> > Silk new P
> > << ( ('attr1' attrNS: ns1) -> 'theId')
> > << ( ('attr2' attrNS: ns2) -> 'blue')
> > << 'The content'.
> >
> > Pros: Conceptually clean.
> >        Dedicated class can be used.
> > Cons: Hard to write.
> >
> >
> >
> > 4. Different binary message than ->
> >
> > Silk new
> > P: { ns1 @ 'attr1' -> 'theId'. ns2 @ 'attr2' -> 'blue'. 'The
> content' }
> >
> > or
> >
> > Silk new P
> > << ( ns1 @ 'attr1' -> 'theId')
> > << ( ns2 @ 'attr2' -> 'blue')
> > << 'The content'.
> >
> > Pros: Easy to write.
> > Cons: Maybe slightly growlixy.
> >        In case of @, Point is abused, though other message may
> create
> > dedicated class.
> >
> >
> >
> > Could you pick up which version would you see as most clean and
> > Smalltalk nature?
> >
> > Thanks, Herby
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "amber-lang" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email to [hidden email].
> > For more options, visit https://groups.google.com/d/optout.
> >

>
>
> Dňa 10. marca 2015 11:04:34 CET používateľ "H. Hirzel"
> <[hidden email]> napísal:
>> And as we deal with a triplet (namespace, attributename, value) a
>
> We are not dealing with a triplet at all. We are dealing with key/value pair
> with compound key.
>
>> regular way to treat data in Smalltalk: create a data class for it.
>>
>> 5. Keyword message with AttributeNS class.
>>
>> Silk new P
>>    << (AttributeNS namespace: 'ns1' attribute: 'attr1' value: 'theId')
>
> This is the worst solution, as it treats namespaced attributes as something
> qualitatively different than normal ones. This is so low-level.
>
> High-level notion of key -> value association should persist. The only
> question is, what to choose to represent the compound key.
>
>>         << 'The content'.
>>
>> Pros: Classical easy to read Smalltalk style
>> Cons: Maybe a bit more effort to implement
>>
>> On 3/9/15, Herby Vojčík <[hidden email]> wrote:
>> > Hello,
>> >
>> > The alternative web / DOM library Silk that is being developed at
>> > herby/silk, has some API choice.
>> >
>> > So far, classical attributes can be added like this (adding <p> with
>> > attributes and content to end of body):
>> >
>> > Silk new
>> > P: { 'id' -> 'theId'. 'class' -> 'blue'. 'The content' }
>> >
>> > or
>> >
>> > Silk new P
>> > << ('id' -> 'theId')
>> > << ('class' -> 'blue')
>> > << 'The content'.
>> >
>> > For namespaced attributes, though, one needs to use namespace, which
>> is
>> > an url string, and the attribute name, so the key is a tuple. Also,
>> it
>> > is good to retain the Association as a way to add these attributes.
>> The
>> > question then is, what to use as a key?
>> >
>> >
>> > 1. Association
>> >
>> > Silk new
>> > P: { ns1 -> 'attr1' -> 'theId'. ns2 -> 'attr2' -> 'blue'. 'The
>> content' }
>> >
>> > or
>> >
>> > Silk new P
>> > << ( ns1 -> 'attr1' -> 'theId')
>> > << ( ns2 -> 'attr2' -> 'blue')
>> > << 'The content'.
>> >
>> > Pros: Easy to write.
>> > Cons: Slight WTF for beginners (implicit parenthesizing).
>> >        Conceptually, ns/name tuple is not a key/value pair.
>> >
>> >
>> >
>> > 2. Array
>> >
>> > Silk new
>> > P: { {ns1. 'attr1'} -> 'theId'. {ns2. 'attr2'} -> 'blue'. 'The
>> content' }
>> >
>> > or
>> >
>> > Silk new P
>> > << ( {ns1. 'attr1'} -> 'theId')
>> > << ( {ns2. 'attr2'} -> 'blue')
>> > << 'The content'.
>> >
>> > Pros: Conceptually nearer to tuple.
>> > Cons: Maybe a bit growlixy.
>> >
>> >
>> >
>> > 3. Keyword message
>> >
>> > Silk new
>> > P: { ('attr1' attrNS: ns1) -> 'theId'. ('attr2' attrNS: ns2) ->
>> 'blue'.
>> > 'The content' }
>> >
>> > or
>> >
>> > Silk new P
>> > << ( ('attr1' attrNS: ns1) -> 'theId')
>> > << ( ('attr2' attrNS: ns2) -> 'blue')
>> > << 'The content'.
>> >
>> > Pros: Conceptually clean.
>> >        Dedicated class can be used.
>> > Cons: Hard to write.
>> >
>> >
>> >
>> > 4. Different binary message than ->
>> >
>> > Silk new
>> > P: { ns1 @ 'attr1' -> 'theId'. ns2 @ 'attr2' -> 'blue'. 'The
>> content' }
>> >
>> > or
>> >
>> > Silk new P
>> > << ( ns1 @ 'attr1' -> 'theId')
>> > << ( ns2 @ 'attr2' -> 'blue')
>> > << 'The content'.
>> >
>> > Pros: Easy to write.
>> > Cons: Maybe slightly growlixy.
>> >        In case of @, Point is abused, though other message may
>> create
>> > dedicated class.
>> >
>> >
>> >
>> > Could you pick up which version would you see as most clean and
>> > Smalltalk nature?
>> >
>> > Thanks, Herby
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "amber-lang" group.
>> > To unsubscribe from this group and stop receiving emails from it,
>> send an
>> > email to [hidden email].
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>

> Herby, Let me take the liberty to disagree :-). **You** think it's the
> worst case. **I** do not. If you do not want to get different opinions
> than there is no need to ask people.
>
> Your remark about not treating Attributes with namespace different
> from the ones without namespace is however valid. So let's take note
> of this:
>
> Regular Smalltalk style to deal with data is to give things names. In
> a 'talkative' way. Some people claim Smalltalk code is

> If the apply this to the problem at hand we get in a Smalltalk-ish style
>
>
>      (AttributeNS attribute: 'attr1' value: 'theId')
>
> with a default and the association ('key' ->  'value') as an
> alternative. (NS=NameSpace)
>
>
> Or to extend this we should generalize the name of the class so that we have
>
>      (Attribute namespace: 'ns1' attribute: 'attr1' value: 'theId')
>
> and
>
>       (Attribute namespace: 'ns1' attribute: 'attr1' value: 'theId')

> Currently there is only one, called #Silk.
>
>
> But as we had in the discussion yesterday I am also very fine with
> your proposal 1
>
> 1. Association
>
> Silk new
>          P: { ns1 ->  'attr1' ->  'theId'. ns2 ->  'attr2' ->  'blue'. 'The
> content' }
>
> or
>
> Silk new P
>    

>
>
> H. Hirzel wrote:
>> Herby, Let me take the liberty to disagree :-). **You** think it's the
>> worst case. **I** do not. If you do not want to get different opinions
>> than there is no need to ask people.
>>
>> Your remark about not treating Attributes with namespace different
>> from the ones without namespace is however valid. So let's take note
>> of this:
>>
>> Regular Smalltalk style to deal with data is to give things names. In
>> a 'talkative' way. Some people claim Smalltalk code is
>
> Silk tries to be less talkative. So that keywords do not hamper reading the
> structure itself - as we are dealing with HTML, there is a structure here.
>
> Inspirations are from mochikit and/or AppJet in how they did it in
> JavaScript, something like this IIRC:
>
>   print(P({id: 'myId', 'class': 'myClass'},
>     "Hello, ",
>     EM("world")
>   ))
>
> but using idioms that are native to Smalltalk (association, blocks, ...).
>
>> self-documenting. Because of well chosen keyword message names. Avoid
>> to many chara
> cters such as { } ->  # with implicit agreements on how
>> to treat the data contained in these structures. Make the information
>> content explicit.
>>
>> With Association ('key' ->  'value') you can do a lot of things but not
>> everything.
>
> Well, I chose Association as the object representing attribute/value pair.
> It just seemed most natural non-too-much-talkative way.
>
>> If the apply this to the problem at hand we get in a Smalltalk-ish style
>>
>>
>>      (AttributeNS attribute: 'attr1' value: 'theId')
>>
>> with a default and the association ('key' ->  'value') as an
>> alternative. (NS=NameSpace)
>>
>>
>> Or to extend this we should generalize the name of the class so that we
>> have
>>
>>      (Attribute namespace: 'ns1' attribute: 'attr1' value: 'theId')
>>
>> and
>>
>>       (Attribute namespace: 'ns1' attribute: 'attr1' value: 'theId')
>
> Having
>
>   aSilk
>     << something
>     << (Attribute namespace: 'ns1' attribute: 'attr1' value: 'theId')
>     << somethingElse.
>
> is too long. If that would
> be the case, I would rather lean to not having high-level support of
> namespaced attributes at all and having to do:
>
>   aSilk
>     << something;
>     attrNS: 'ns1' at: 'attr1' put: 'theId';
>     << somethingElse.
>
> But I don't like _not_ having the `<<`-able object,
> because it then prevents doing << {obj1. obj2. obj3} style.
>
>> and allow the association to be a shortcut for it.
>>
>>       ('attr1' ->  'theld')
>
> I see Association as _the_ attr/value pair, not the shortcut for it. Re
> less-wordy-structure philosophy from earlier.
>
>> This will add a second class to the package https://github.com/herby/silk
>
> Adding class is not a problem (albeit for key, not from whole pair), as
> shown in options 3 and 4.
>
>> Currently there is only one, called #Silk.
>>
>>
>> But as we had in the discussion yesterday I am also very fine with
>> your proposal 1
>>
>> 1. Association
>>
>> Silk new
>>          P: { ns1 ->  'attr1' ->  'theId'. ns2 ->  'attr2' ->  'blue'.
>> 'The
>> content' }
>>
>> or
>>
>> Silk new P
>>
>       <<  ( ns1 ->  'attr1' ->  'theId')
>>          <<  ( ns2 ->  'attr2' ->  'blue')
>>          <<  'The content'.
>>
>> Pros: Easy to write.
>> Cons: Slight WTF for beginners (implicit parenthesizing).
>>        Conceptually, ns/name tuple is not a key/value pair.
>>
>> HTH
>> --Hannes
>
> --
> You received this message because you are subscribed to the Google Groups
> "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>