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

Groups > comp.lang.javascript > #29688 > unrolled thread

Refer object within itself

Back to article view | Back to comp.lang.javascript

Contents

  Refer object within itself Andrew Poulos <ap_prog@hotmail.com> - 2016-02-26 22:50 +1100
    Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-26 04:51 -0800
      Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-02-26 14:15 +0100
    Re: Refer object within itself "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-02-26 16:43 +0100
      Re: Refer object within itself Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-26 19:25 +0100
    Re: Refer object within itself Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-26 19:23 +0100
    Refer object within itself Ram Tobolski <ramtob@gmail.com> - 2016-02-28 10:06 -0800
      Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-02-28 23:07 +0100
        Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-02-28 23:23 +0100
          Re: Refer object within itself Stefan Weiss <krewecherl@gmail.com> - 2016-02-29 00:11 +0100
          Re: Refer object within itself Aleksandro <aleksandro@gmx.com> - 2016-02-29 14:49 -0300
            Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-02-29 19:49 +0100
              Re: Refer object within itself Aleksandro <aleksandro@gmx.com> - 2016-03-01 10:48 -0300
                Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-01 17:22 +0100
                  Re: Refer object within itself Aleksandro <aleksandro@gmx.com> - 2016-03-01 15:07 -0300
                    Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-01 20:26 +0100
                      Re: Refer object within itself Aleksandro <aleksandro@gmx.com> - 2016-03-04 21:53 -0300
                        Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-05 14:22 +0100
                          Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-05 10:17 -0800
                            Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-06 11:59 +0100
                              Re: Refer object within itself Ram Tobolski <ramtob@gmail.com> - 2016-03-06 10:48 -0800
                              Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-06 19:07 -0800
                                Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-07 10:44 +0100
                                  Re: Refer object within itself Aleksandro <aleksandro@gmx.com> - 2016-03-07 12:54 -0300
                                    Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-07 17:59 +0100
                                  Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-07 13:44 -0800
                                    Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-07 22:59 +0100
                                      Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-07 17:00 -0800
                                        Re: Refer object within itself "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-08 10:24 +0100
                                          Re: Refer object within itself Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-08 13:03 -0800

Page 2 of 2 — ← Prev page 1 [2]

#29836

This then may dissolve the remaining doubts:

var foo = {
   'name':'bar',
   'width':600,
   get heightDoNotSetMeEvertjan(){return this.width * 2;}
};

console.log(foo.heightDoNotSetMeEvertjan) // "1200"

[toc] | [prev] | [next] | [standalone]

#29843

Evertjan. wrote:
> Scott Sauyet wrote:
>> Evertjan. wrote:
>>> Aleksandro wrote: 

>>>> But it did the job. :)
>>> [ ... ]
>>> The answer was inexact and so unfit for this NG, where many others
>>> could be set on the wrong foot.
>>> [ ... ]
> 
>> As Stefan pointed out, the 
>> answer from Ram Tobolski was the best one supplied, 
> 
> An absolute "the best one"???????????? [see below]

Yes, simplest in both conception and implementation.  it does the
job required and will not throw the errors you're worried about
if used correctly.  With Stefan's (again obvious) extension it
will not throw errors however it's used.

It does make an assumption that is perhaps not warranted, that
the height should remain linked to the original width.  And if
that's not true, then the solution I supplied might be best,
but mine doesn't really meet the OP's request of "How do I 
reference to the object itself within the object?"  It is, I
believe, reasonably close in spirit, but it instead refers to
a value in the function scope that will become a closure
available to the object.  That's not the object itself.


 
>> [ ... ] 

>> So, can you see anything wrong with this suggestion, or with the 
>> slight extension proposed by Stefan?
> 
> I agree, it was the best iyho, but not in imho.
>  
> var foo {  "name":"bar", "width":600 };
> foo.height = foo.width * 2;

The OP made it fairly clear that he knew about this option and was
looking for something better, something again that, would allow
him to "reference to the object itself within the object."


> ... makes results in what is real usefull,
> as it does not suffer from the error possibillity,
> if someone later wants to change foo.height.
> 
> if foo.height is just a 'getter', a later:
> 
> foo.height = foo.width * 3;
> 
> using 'getter' would throw unexpectedly:
> 
> >// Uncaught TypeError: Cannot set property height of #<Object> 
> >// which has only a getter
> 
> which imho does not getter better.

And if we use your solution, a user who sets the height will be
allowed to silently do so, even if the real requirement is to 
maintain a constant 2 : 1 ratio.


> The 'getter' method is nice and usefull, 
> but less simple and more error-prone,
> as most shortcut codes are.
> 
> Mixing 'getters' with ordinary object properties,
> would perhaps need a naming-convention that alerts the unwary,
> like:
> 
> var foo = { 
>    'nameProperty':'bar', 
>    'widthProperty':600, 
>    get heightGetter(){return this.width * 2;} 
> };

That sounds like ridiculous overkill to me, but perhaps you
work on library projects or large public APIs where you have
to be wary of what others are going to do to objects you
create.

I don't know about the OP, but I would not choose to do that
for any small or medium sized project.  I would prefer to 
leave it to whatever conventions or documentation the project
has that one cannot set the height of such objects.  It
doesn't sound likely to create subtle bugs.  If things go 
wrong, it should do so obviously and soon.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29844

Scott Sauyet <scott.sauyet@gmail.com> wrote on 07 Mar 2016 in 
comp.lang.javascript:

>> An absolute "the best one"???????????? [see below]
> 
> Yes, simplest in both conception and implementation. 

What nonsense, this is just your opinion,
while my opinion is different.

It is certeinly not the simplest in conception, imho,
unless you believe in immaculate ones.

It is certainly not the simplest one in implementation, imho,
since you have to know about or read-up on getters.

> it does the job required and will not throw the errors 
> you're worried about if used correctly.  

"if used correctly", that is just the crux.

If the Highway-Code** were always used correctly and immaculately, 
traffic lights would never be needed to avoid collisions 
and consequent corporal damages. 

** <https://www.gov.uk/guidance/the-highway-code>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29848

On 07/03/16 06:44, Evertjan. wrote:
> Scott Sauyet <scott.sauyet@gmail.com> wrote on 07 Mar 2016 in 
> comp.lang.javascript:
> 
>>> An absolute "the best one"???????????? [see below]
>>
>> Yes, simplest in both conception and implementation. 
> 
> What nonsense, this is just your opinion,
> while my opinion is different.

What nonsense, this is just your opinion,
while nobody else seems to share yours anyway.

[toc] | [prev] | [next] | [standalone]

#29849

Aleksandro <aleksandro@gmx.com> wrote on 07 Mar 2016 in 
comp.lang.javascript:

> On 07/03/16 06:44, Evertjan. wrote:
>> Scott Sauyet <scott.sauyet@gmail.com> wrote on 07 Mar 2016 in 
>> comp.lang.javascript:
>> 
>>>> An absolute "the best one"???????????? [see below]
>>>
>>> Yes, simplest in both conception and implementation. 
>> 
>> What nonsense, this is just your opinion,
>> while my opinion is different.
> 
> What nonsense, this is just your opinion,

Of course it is just my opinion,
I reperatedly said that,
that does not make it nonsense.

I do not think it should be about "the best one" by majority shouting,
but arguments of opinions should be discussed.

> while nobody else seems to share yours anyway.

That does not seem so to me, 
because my [sound, imho] reasoning is not contradicted.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29850

Evertjan. wrote:
> Scott Sauyet wrote:
> 
>>> An absolute "the best one"???????????? [see below]
>> 
>> Yes, simplest in both conception and implementation. 
> 
> What nonsense, this is just your opinion,

Surely that's just your opinion about the matter, right?


> while my opinion is different.

Do you really believe it necessary to apologize for every opinion
stated on USENET with "IMHO"?


> [ ... ]
>> it does the job required and will not throw the errors 
>> you're worried about if used correctly.  
> 
> "if used correctly", that is just the crux.

That is always the crux.  The OP has not weighed back in on the issue,
but most of us are making an assumption that seems very different from
what you're assuming.

You seem to be assuming that only the initial ratio is important.  If
that's the case, then a technique like mine or yours is fine; the choice
might depend on whether one wants a mutable or immutable object, although
I didn't go as far as demonstrating actual immutable versions.

Most everyone seems to assume that the continued 2:1 ratio of 
height:width is essential.  If that's the case, then your technique 
fails, and allows one to get objects into an inconsistent state.  
That, to my mind, is significantly worse than throwing an error.

Probably the reason that most people seem to be making the latter 
assumption is that the OP specifically mentioned your technique, but
was looking for something better, and asked, "How do I reference to
the object itself within the object?"  Your code does not answer this
question.
 
  -- Scott

[toc] | [prev] | [next] | [standalone]

#29851

Scott Sauyet <scott.sauyet@gmail.com> wrote on 07 Mar 2016 in 
comp.lang.javascript:

>> while my opinion is different.
> 
> Do you really believe it necessary to apologize for every opinion
> stated on USENET with "IMHO"?

You still don't get it.

My opinion always is imho, 
others like you foolishly pretend otherwize.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29852

Evertjan wrote:
> Scott Sauyet wrote:
> 
>>> while my opinion is different.
>> 
>> Do you really believe it necessary to apologize for every opinion
>> stated on USENET with "IMHO"?
> 
> You still don't get it.
> 
> My opinion always is imho, 
> others like you foolishly pretend otherwize.

No, that's not what I believe.  I simply don't think it's necessary
or even helpful to plop "IMHO" everywhere when a discussion that
is all about opinions is underway.

Now, back to the original problem.  Does your solution -- IYHO, if
you like -- meet the requirements as per the original post?  I've
already argued that it does not "reference to the object itself within
the object," and therefore is disqualified.  This seems crystal-clear
to me.  Obviously you can choose to argue that the requirement is
nonsense, but do you agree with my assessment?  Or do you think that
it does meet the original requirements?

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29856

Scott Sauyet <scott.sauyet@gmail.com> wrote on 08 Mar 2016 in 
comp.lang.javascript:

> Evertjan wrote:
>> Scott Sauyet wrote:
>> 
>>>> while my opinion is different.
>>> 
>>> Do you really believe it necessary to apologize for every opinion
>>> stated on USENET with "IMHO"?
>> 
>> You still don't get it.
>> 
>> My opinion always is imho, 
>> others like you foolishly pretend otherwize.
> 
> No, that's not what I believe.

You are entitled tou your believes,
I believe in sound reasoning based on evidence.

> I simply don't think it's necessary
> or even helpful to plop "IMHO" everywhere when a discussion that
> is all about opinions is underway.

Well, "necessary" and "everywhere", like your "no one" and "the best way". 
so absolute!

> Now, back to the original problem.  Does your solution -- IYHO, if
> you like -- meet the requirements as per the original post?  I've
> already argued that it does not "reference to the object itself within
> the object," and therefore is disqualified. 

and now "disqualified", 
all reasoning stops where one party uses such absolute references.

> This seems crystal-clear to me. 

"crystal-clear" is not an argument.

> Obviously you can choose to argue that the requirement is
> nonsense, but do you agree with my assessment? 

As I wrote, I think the "getter" method is a nice method,
but can give way terrible errors perhaps at runtime a half year later.

Therefore I suggested to develop a naming convention, clearly distinguishing 
between "standard" value-properties of objects and "getter"-properties.

[Something like as there is now between properties and methods, the latter 
needing () behind the name]

*** A "getter" seems a method disguised as a property. ***

Perhaps that disguise is my main concern and I did not declare that earlier,
because I did not visualize it yet. 

That is [imho, sorry, yes, anyway] the importance of discussion: shaping of 
views and adapting with opposing views. For me, discussion has its own joy, 
independent of the merits of the result. Read the Talmut for such 
discussions.

> Or do you think that
> it does meet the original requirements?

I think the OP did not know what troubles lay ahead for him,
when the "getter-method" was introduced in the answer.

Whether he wanted a "static" or a "dynamic" value is not clear to me,
perhaps we should have given both answers for him to choose.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29859

Evertjan wrote:
> Scott Sauyet wrote:
>> Evertjan wrote:
>>> Scott Sauyet wrote:

>> Now, back to the original problem.  Does your solution -- IYHO, if
>> you like -- meet the requirements as per the original post?  I've
>> already argued that it does not "reference to the object itself within
>> the object," and therefore is disqualified. 
> [ ... ] 
>> This seems crystal-clear to me. 
> 
> "crystal-clear" is not an argument.

So now you're criticizing it when I do make it clear that something is
my opinion?  :-)
 
>> Obviously you can choose to argue that the requirement is
>> nonsense, but do you agree with my assessment? 
> 
> As I wrote, I think the "getter" method is a nice method,
> but can give way terrible errors perhaps at runtime a half year later.

Do you think that is true of the simple extension Stefan offered?

    var foo = { 
      name: "bar", 
      width: 600, 
      get height () { return this.width * 2; }, 
      set height (h) { this.width = h / 2; }, 
    }; 

AFAICT [1], this covers any such objections.  It also meets the initial
criterion I keep stressing, that of being able to "reference to the 
object itself within the object," and it enforces the requirement
several posters have inferred that the height:width ratio must be
maintained.

Do you see problems with it?  Do you think it might still cause errors
some months later?  


> Therefore I suggested to develop a naming convention, clearly distinguishing 
> between "standard" value-properties of objects and "getter"-properties.
> 
> [Something like as there is now between properties and methods, the latter 
> needing () behind the name]

That's interesting.  This is a distinction clearly intentionally blurred
by the language.  ISTM [1] that the entire goal of the `get`/`set` syntax
is to allow one to write functions to handle what would normally look like
dot-based property access.  To me this is a good thing.
 
> *** A "getter" seems a method disguised as a property. ***

You could say that.  You could also say that getters/setters are
an alternative implementation of a property.  In fact they represent a
strictly more powerful version than the traditional property.  But this
is nothing new in Javascript.  `Object.defineProperty` has given many
capabilities, and many combinations.  This is just a particularly 
simple one to use.


> Perhaps that disguise is my main concern and I did not declare that earlier,
> because I did not visualize it yet. 

To me [1] that is not something to discover.  That is part of the joy of
getters/setters.


> That is [imho, sorry, yes, anyway] the importance of discussion: shaping of 
> views and adapting with opposing views. For me, discussion has its own joy, 
> independent of the merits of the result. Read the Talmut for such 
> discussions.

I absolutely agree with you on this.  I believe [1] our contrast is mostly
one of _style_.  I'm perfectly happy to say, "That's great!" or, "That's
nonsense!", and don't find any need to say, "That looks great to me! or "I find that to be nonsense!"

 
>> Or do you think that
>> it does meet the original requirements?
> 
> I think the OP did not know what troubles lay ahead for him,
> when the "getter-method" was introduced in the answer.

I'd really like to know if you see any flaws in Stefan's extension.


> Whether he wanted a "static" or a "dynamic" value is not clear to me,
> perhaps we should have given both answers for him to choose.

Perhaps.  But he gave a static answer just like yours, and I gave another
static one.  The answer under discussion still seems to best one for a
dynamic value, but I'd love to hear if you have an alternative.

  [1]: See, I can do it!

  -- Scott

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web