Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #30240

Re: Comparing some of the ways to create objects

Show all headers | View raw

John Harris wrote:
> Scott Sauyet wrote:
>> John Harris wrote:
>>> Scott Sauyet wrote:

>> I would argue that in fact, a variant of my #5 is substantially
>> simpler:
>>
>>    function thing8(phrase) {
>>      return {
>>        count: 0,
>>        toString: function() {return phrase;},
>>        incr: function() {this.count++},
>>      };
>>    } // thing8
>>
>> There are certainly legitimate reasons not to like this.  (See Stefan
>> Weiss' response for some of them.)  But if simplicity is you chief
>> concern, then this one beats them all.
 
>>> Unfortunately, private encapsulation is not an ECMAScript feature
>>> (yet).
>>
>> But it is.  I offered two ways to achieve it.  Stefan also mentioned
>> techniques involving Symbols and WeakMaps.  Again, my main point is
>> that, if you're going to do OOP, there are many different techniques 
>> to achieve it.
> 
> Then there's also get and set methods. But there isn't a 'private'
> keyword yet.


Yes, JS is not an OOP language.  It's not an imperative language.  It's 
not a functional language.  It's a multi-paradigm language with a 
reasonable set of prototypal OOP features and a basic set of functional 
features that is used by many beginners as a simple imperative language.

But the privacy offered by these techniques, even without a keyword is 
actually much stronger than that offered by Java or C# (I don't know 
about C++.)  In those languages, you can use reflection to to still get 
at the field.  In Javascript closure-based privacy, it's really hidden.
[1]

>> To me, your list didn't offer ways to solve some of the most essential
>> problems in OOP;
> 
> The title says 'comparing' and 'ways', not problems that some people
> need to solve.

Ok, I've offered now five additional ways, as I found none of the 
originals compelling.  But perhaps I should simply shut up because I 
mostly don't find OOP particularly compelling.

 
>> instead it gave three barely-distinguishable versions of the same basic
>> idea
> 
> It's true, they are barely distinguishable, but some people are
> absolutely adamant that ECMAScript is one of these ways and not the
> other.

Sure.  Were you mostly trying to make the point that these are equally 
legitimate?  If so, I missed it, perhaps because that's blindingly 
obvious to me.  Clearly I believe there are many other ways that might be 
still more reasonable.

>> and seemed to claim that they covered everything important in OOP.
> 
> That would be a misunderstanding of the title.

I don't put much stock in USENET titles.  But you're right, I didn't 
think much about the title in my responses.


>>>> Do you believe your list captures the essence of the set of
>>>> reasonable object creation techniques in Javascript?
>>> 
>>> It captures the essence of the different ways, without complicating
>>> the picture. E.g The per-object data is shown in one list, not
>>> scattered around arguments and local variables.
>>
>> Version #8 above does that more succinctly.  Should that be the only 
>> one we promote?
> 
> Using function arguments as pseudo-properties is not really succinct.

I'm afraid I don't follow this.

I was discussing the version quoted above, in which a function returns 
object described by an object literal containing the properties `count`, 
`toString`, and `incr`, the first initially hardcoded to a number, the 
second to a function which references the `phrase` parameter of the 
function, and the third a function which updates the local reference to 
the `count` property.

Are you saying that the fact that `phrase` is stored in the closure makes 
this less succinct?  That seems backwards to me.  But obviously we could 
change it trivially so that the property is stored in the returned 
object.  But that once again makes mutable something that arguably should 
remain immutable.

I think working in the functional programming world long enough may have 
colored how I see OOP as well.  I prefer immutable objects, and even when 
they are mutable, I prefer to contain the mutation as much as possible.

For this reason, I still prefer #5 to #8.

    function thing5(phrase) {
      var count = 0;
      return {
        toString: function() {return phrase;},
        incr: function() {count++},
        get count() {return count;}
      };
    } // thing5

In this version, the user cannot break the object as we might with #8, or 
with any of the versions in the OP:

    var a8 = thing8("Hello from thing8 a8");
    a8 + ': ' + a8.count; //=> "Hello from thing8 a8: 0"
    a8.incr();
    a8 + ': ' + a8.count; //=> "Hello from thing5 a8: 1"
    a8.count = "hey look, a unicorn"
    a8 + ': ' + a8.count; //=> "Hello from thing5 a8: hey look, a unicorn"
    a8.incr();
    a8 + ': ' + a8.count; //=> "Hello from thing5 a8: NaN"

>>>>  [1]: <https://davidwalsh.name/javascript-objects-deconstruction>
>> In any case, I would personally choose something like #5 / #8 for most
>> of my work.  I find this clearest and most expressive.
> 
> Have you wondered what his so simple final diagram would look like if
> you add all the lines and boxes for accessing function arguments and
> local variables ?

The technique Kyle Simpson suggests does not use local closures for any 
such thing.  That was a different example, #6 in my list.

> An aside : There's a video talk by the inventor of Smalltalk where he
> makes it very clear that if a language hasn't got *every* feature of
> Smalltalk then it isn't OO. I wonder if Dave Walsh has seen it.

I'd be interested in seeing a reference if you have one, because that 
does not sound like his ideas at all.

I think this bears repeating:

  (from my <news:655ac788-5a00-447c-a148-08287f3c87bd@googlegroups.com>)

| In a response to (our own?) Stefan Ram, Alan Kay, who coined the
| term "object-oriented", said, "OOP to me means only messaging, local
| retention and protection and hiding of state-process, and extreme
| late-binding of all things."
| 
| The entire exchange [*] is well worth a read.  Dr. Kay also partially
| disavows at least the word "polymorphism" as not flexible enough to
| capture what he was looking for, and more firmly disavows existing
| (circa 2003) strong type systems.
| 
| While I don't believe that Dr. Kay has the right to dictate the ongoing
| discussion of the term, he is also in a quite privileged place with
| respect to it.  These ideas are worth serious consideration.  And to
| me, they are quite convincing. 
| 
| [*]: <http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/
doc_kay_oop_en> 


> 
>>And I suppose that's why I challenge the notion that #1 - #3 are
>>paticularly relevent.
> 
> I think we have to agree to disagree on the subject of preferred
> creation methods.

Yes, clearly we have very different ideas of what's important.   And 
we're not likely to convince one another.  If you would, though, I'd 
appreciate it if you could clarify what you mean by "Using function 
arguments as pseudo-properties is not really succinct."



[1]: I believe I've recently seen a technique that might allow for the 
breaking of this privacy.  I thought it was on Gleb Bahmutov's blog 
(https://glebbahmutov.com/blog/), but I don't spot it when I go back to 
look.  It was quite obscure, and Node.js only, if I recall correctly.

  -- Scott

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-03 16:09 +0100
  Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-04 04:15 +0000
    Re: Comparing some of the ways to create objects Stefan Weiss <krewecherl@gmail.com> - 2016-04-04 15:20 +0200
      Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-05 04:04 +0000
    Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-04 16:48 +0100
      Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-05 04:04 +0000
        Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-07 15:07 +0100
          Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-08 01:10 +0000
            Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-08 14:55 +0100
    Re: Comparing some of the ways to create objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-04 22:12 +0200
      Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-05 09:57 +0100
    Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-06 16:41 +0100
      Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-06 23:42 +0000
        Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-07 16:09 +0100
          Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-08 02:05 +0000
            Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-08 15:43 +0100
              Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-09 00:01 +0000
                Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-09 16:46 +0000
                Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-10 16:51 +0000
                Re: Comparing some of the ways to create objects Stanimir Stamenkov <s7an10@netscape.net> - 2016-05-08 17:27 +0300
                Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-10 11:31 +0100
                Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-10 11:52 +0100

csiph-web