Silk sample (was: Re: [amber-lang] Poll: Silk - what is best Smalltalkish way to add namespaced attribute?)

> An example to be evaluated in an Amber workspace.
> https://gist.github.com/hhzl/a0685140950332726ed3
>
> It is is JavaScript code translated to Amber Smalltalk. No Domite nor
> Silk library loaded.
>
> How should it look like in Domite / Silk ?
>
>
>
> | svg circle |

>
> "Translated and adapted from:
> http://stackoverflow.com/questions/8215021/create-svg-tag-with-javascript"
>
> On 3/10/15, Herby Vojčík<[hidden email]>  wrote:
>>
>> 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.
>>
>