Prev: How to Pump $1,000s in CASH & Checks to your door.
Next: Suggestion for FAQ, *OR* has it been done (URL?)
From: Alex Shabanov on 17 May 2010 09:38
On May 17, 1:24 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
>
> > Could you please clarify what strategy is acceptable from your point
> > of view?
>
> AISB, polymorphism, unless host objects are involved.  Let the (values
> converted into) objects have a method with the same name that does the
> serialization.
>

This works bad for situations where an incoming object taken from,
say, JSON response.
Of course, for some cases the visitor pattern might be used (I guess
this is what you mean by polymorphism approach), but not always.
E.g. consider "named parameters" feature when you have one function
that might take a big variety of incoming objects, say:
print("sample arg")
print({ expr: "sample expr", value: 45 })
print({ expr: "sample expr", value: "sample val" })
print({ snippet: "Huge block of text..." })
print(new SomePrintableObject(arg1, arg2,..))
And for each line a different printing algorithm should be used.

> > Too error prone, from my point of view.
>
> As for error-proneness, your approach beats almost everything else by
> inches.

Your criticism is groundless.
From: Thomas 'PointedEars' Lahn on 17 May 2010 12:07
Alex Shabanov wrote:

> Thomas 'PointedEars' Lahn wrote:
>> > Could you please clarify what strategy is acceptable from your point
>> > of view?
>> AISB, polymorphism, unless host objects are involved. Let the (values
>> converted into) objects have a method with the same name that does the
>> serialization.
>
> This works bad for situations where an incoming object taken from,
> say, JSON response.

No.

> Of course, for some cases the visitor pattern might be used (I guess
> this is what you mean by polymorphism approach),

I have not studied the Visitor pattern in detail, but from its abstract ISTM
I mean quite the contrary: I do not want to separate the algorithm from the
object structure it operates on, I want to join them.

> but not always.
>
> E.g. consider "named parameters" feature when you have one function
> that might take a big variety of incoming objects, say:
> print("sample arg")
> print({ expr: "sample expr", value: 45 })
> print({ expr: "sample expr", value: "sample val" })
> print({ snippet: "Huge block of text..." })
> print(new SomePrintableObject(arg1, arg2,..))
> And for each line a different printing algorithm should be used.

So what? either the referred supported *native* object already has a method
like e.g. serialize() or its prototype can be (temporarily) augmented with
one:

/*
* This one should be temporarily only, so the RHS should probably be kept
* in a closure
*/
Object.prototype.serialize = function () {
/* ... */
};

/* No real harm in keeping this one */
String.prototype.serialize = function () {
/* ... */
};

/* Can be provided along with the declaration */
SomePrintableObject.prototype.serialize = function () {
/* ... */
};

All your print() method (which is an unwise identifier, BTW) needs to do
then is essentially to check for the existence of this method on the passed
value (of course, if you augmented temporarily you would choose a much less
likely identifier, like one returned by jsx.object.findNewProperty()), call
it, and return its result.

>> > Too error prone, from my point of view.
>>
>> As for error-proneness, your approach beats almost everything else by
>> inches.
>
> Your criticism is groundless.

No, it is not. Search the archives, including those jQuery threads (they
made the same mistake as you, or vice-versa).


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Alex Shabanov on 18 May 2010 04:40
On May 17, 8:07 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Alex Shabanov wrote:
> ...
> I have not studied the Visitor pattern in detail, but from its abstract ISTM
> I mean quite the contrary:  I do not want to separate the algorithm from the
> object structure it operates on, I want to join them.
>
> > but not always.
>
> > E.g. consider "named parameters" feature when you have one function
> > that might take a big variety of incoming objects, say:
> > print("sample arg")
> > print({ expr: "sample expr", value: 45 })
> > print({ expr: "sample expr", value: "sample val" })
> > print({ snippet: "Huge block of text..." })
> > print(new SomePrintableObject(arg1, arg2,..))
> > And for each line a different printing algorithm should be used.
>
> So what?  either the referred supported *native* object already has a method
> like e.g. serialize() or its prototype can be (temporarily) augmented with
> one:
>
>   /*
>    * This one should be temporarily only, so the RHS should probably be kept
>    * in a closure
>    */
>   Object.prototype.serialize = function () {
>     /* ... */
>   };
>
>   /* No real harm in keeping this one */
>   String.prototype.serialize = function () {
>     /* ... */
>   };
>
>   /* Can be provided along with the declaration */
>   SomePrintableObject.prototype.serialize = function () {
>     /* ... */
>   };
>
> All your print() method (which is an unwise identifier, BTW) needs to do
"print" identifier was taken just to illustrate an idea.
> then is essentially to check for the existence of this method on the passed
> value (of course, if you augmented temporarily you would choose a much less
> likely identifier, like one returned by jsx.object.findNewProperty()), call
> it, and return its result.

I knew about the possibility to extend prototypes but never thought of
it in that way, I mean temporary extension or "augmentation".
This is quite an interesting approach.

>
> >> > Too error prone, from my point of view.
>
> >> As for error-proneness, your approach beats almost everything else by
> >> inches.
>
> > Your criticism is groundless.
>
> No, it is not.  Search the archives, including those jQuery threads (they
> made the same mistake as you, or vice-versa).

Thank you very much for your comments.

>
> PointedEars
> --
>     realism:    HTML 4.01 Strict
>     evangelism: XHTML 1.0 Strict
>     madness:    XHTML 1.1 as application/xhtml+xml
>                                                     -- Bjoern Hoehrmann

Alex
First  |  Prev  | 
Pages: 1 2 3
Prev: How to Pump $1,000s in CASH & Checks to your door.
Next: Suggestion for FAQ, *OR* has it been done (URL?)