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

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

Objects what are they.

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

Contents

  Objects what are they. jonas.thornvall@gmail.com - 2019-04-25 02:16 -0700
    Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-25 02:40 -0700
    Re: Objects what are they. groovee@cyberdude.com - 2019-04-25 09:12 -0700
      Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-25 18:37 +0100
        Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-25 23:41 -0700
          Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-25 23:56 -0700
            Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 00:00 -0700
          Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-26 10:45 +0100
            Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 04:37 -0700
              Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-26 19:41 +0100
                Re: Objects what are they. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-04-26 21:11 +0200
                  Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 13:23 -0700
                    Re: Objects what are they. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-04-26 23:32 +0200
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 15:11 -0700
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 15:24 -0700
                        Re: Objects what are they. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-04-27 11:52 +0200
                    Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-27 11:17 +0100
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-27 05:00 -0700
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-27 05:06 -0700
                  Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-27 11:08 +0100
            Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-28 05:03 -0700
              Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-28 18:11 +0200
                Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 03:43 -0700
                  Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-29 14:11 +0200
                    Re: Objects what are they. John-Paul Stewart <jpstewart@sympatico.ca> - 2019-04-29 11:15 -0400
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 08:41 -0700
                        Re: Objects what are they. John-Paul Stewart <jpstewart@sympatico.ca> - 2019-04-29 15:16 -0400
                          Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 15:56 -0700
                            Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 16:08 -0700
                              Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 16:30 -0700
                      Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-29 09:44 -0700
                    Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 08:31 -0700
          Re: Objects what are they. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-04-26 13:48 +0200
        Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 00:25 -0700
          Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 00:30 -0700
          Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-26 01:06 -0700
        Re: Objects what are they. groovee@cyberdude.com - 2019-04-26 07:41 -0700
          Re: Objects what are they. Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-04-26 15:39 +0000
            Re: Objects what are they. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-26 23:23 +0200
              Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-27 11:25 +0100
                Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-27 04:10 -0700
                  Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-27 04:17 -0700
                    Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-27 14:39 +0100
                      Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-27 10:16 -0700
                        Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-28 10:53 +0100
                          Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-29 07:08 -0700
                            Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-30 11:03 +0100
                  Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-27 14:43 +0100
          Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-26 19:36 +0100
            Re: Objects what are they. groovee@cyberdude.com - 2019-04-28 08:53 -0700
              Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-29 10:35 +0100
          Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-27 17:45 +0200
            Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-27 10:19 -0700
              Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-27 20:57 +0200
                Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-29 06:53 -0700
                  Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-29 15:08 +0100
                    Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-29 19:21 +0200
                      Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-29 20:06 +0100
                        Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-29 23:09 +0200
                          Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-30 10:39 +0100
                            Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-30 14:06 +0200
                              Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-30 05:26 -0700
                                Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-30 19:14 +0200
                                  Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-30 12:07 -0700
                                    Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-05-01 14:29 +0100
                                      Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-05-01 07:52 -0700
                                        Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-05-01 18:34 +0100
                                Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-30 18:27 +0100
                              Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-04-30 18:22 +0100
                                Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-30 22:25 +0200
                                  Re: Objects what are they. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-05-01 15:15 +0100
                  Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-29 18:31 +0200
                    Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-29 09:42 -0700
                      Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-29 19:42 +0200
                    Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-29 17:35 -0700
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-30 00:18 -0700
                        Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-30 06:00 -0700
                          Re: Objects what are they. Julio Di Egidio <julio@diegidio.name> - 2019-04-30 06:16 -0700
                            Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-30 06:38 -0700
                      Re: Objects what are they. jonas.thornvall@gmail.com - 2019-04-30 06:21 -0700
            Re: Objects what are they. groovee@cyberdude.com - 2019-04-28 08:43 -0700
              Re: Objects what are they. "R.Wieser" <address@not.available> - 2019-04-28 19:02 +0200
      Re: Objects what are they. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-26 23:07 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#36467

Den fredag 26 april 2019 kl. 11:45:53 UTC+2 skrev John G Harris:
> On Thu, 25 Apr 2019 23:41:19 -0700 (PDT), jonas.thornvall@gmail.com
> wrote:
> 
>   <snip>
> >Hello John, i just need to know, ***how do i declare this nested object***, either i am  fucking stupid because i can't find any similar examples, and i really tried to figure it out by myself ***trial and error*** mostly error LoL
> >
> >Synth[i].Bank[j].Instrument[k].Note[l].Notename="Hihat";
>   <snip>
> 
> The structure is a tree. You don't declare it, you build it. Well, you
> do have to declare the object that holds it all.
> 
> 
>   var synths = [];  
>     // The top (or is it the bottom?) of the tree structure
> 
>   synths[i] = newSynth();  
>     // That's one of your synth objects created
> 
>   synths[i].banks[j] = newBank();
>     // That's one of its bank objects created
> 
>   synths[i].banks[j].instruments[k] = newInstrument();
>     // That's one of its instrument objects created
> 
>   synths[i].banks[j].instruments[k].notes[l] = newNote();
>     // That's one of its note objects created
> 
>   synths[i].banks[j].instruments[k].notes[l].name = "Hihat";
>     // That's the note object given a name
> 
>   John

Back to the thread.
Is this also the way others would implemented something like followin pseudo code "structure" in Javascript? The above is fully clear to me, but it is stringed together from parts, but maybe that is just how you do it in Javascript?

One would like something like a structure explanation for the "object?". Otherwise it get hard to read the code? If it just parts stringed together?

Obj. Synth: 
   //  Prop. 
   Synth[](InstrumentIndex,InstrumentName,(Bank)) 
   //  SubProp/obj. 
   Bank[](Bankindex,Bankname,(Instrument)) 
   //  SubProp/obj. 
   Instrument[](Instrumentindex,Instrumentname,(Note)) 
   //  SubProp.     
   Note[](NoteIndex,Notename); 

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

#36470

Jonas,

> The above is fully clear to me, but it is stringed together
> from parts,

Those "parts" as you call it are the objects. :-)

> but maybe that is just how you do it in Javascript?

How you /can/ do it.    You can, if you want, still do it with arrays too. 
After all, you do not seem to need any (user defined!) functions on any of 
those objects.    As such you can therefore currently still use the names 
"object" and "array" interchangably.

> Is this also the way others would implemented something
> like followin pseudo code "structure" in Javascript?

Definitily not.   For starters, you have "Instrumentindex,Instrumentname" 
twice in there.  Also, none of the objects (the left-most names) are arrays, 
they are objects (1).  They /contain/ arrays (the right-most names).

Furthermore, the XxxxIndex thingies there are properties of the arrays (2), 
and do not need to be seperatily stored.

(1) than again, you are still looking at those objects as if they are arrays 
...   Whis, in this particular case, they well might be. :-)

Your "Obj Synth" is special: it currently does not contain anything else 
than an array called "Bank".  Though it could also contain another property 
with the name of the play.  "Mozards fitfth" for instance.

Your 'Bank" object contains two properties: One is its name, and the second 
an array with "Instrument"s

Your "Instrument" object contains two properties: One is its name, and the 
second an array with "Note"s

Your "Note" object (currently) contains a single property, the notes name.

(2) you do not need an index to be able to add or loop thru an array. 
Though I can imagine that its handy when looping thru all the notes.  (for 
example, to add new element to an array you can use "{arrayname}.push(new 
item)")

> Obj. Synth:
>    //  Prop.
>    Synth[](InstrumentIndex,InstrumentName,(Bank))
> [Snip]

Nope.

Obj. "Synth":
  //Prop #1 - "Banks", an array holding zero or more "Bank" objects

 Obj "Bank":
  //Prop #1 - "Name", a string
  //Prop #2 - "Instruments", an array holding zero or more "Instrument" 
objects

 Obj "Instrument":
  //Prop #1 - "Name", a string
  //Prop #2 - "Notes", an array holding zero or more "Note" objects

  Obj "Note":
  //Prop #1 - "Name" - a string indicating a certain note (or 
sub-instrument).

> One would like something like a structure explanation for the "object?".

John G gave you one.  The above is another. But I guess you could also put 
it down like the below :

 Synth[Banks[BankName,Instruments[InstrumentName,Notes[NoteName]]]]

Hope that helps.

Regards,
Rudy Wieser

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

#36473

Den söndag 28 april 2019 kl. 18:11:54 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > The above is fully clear to me, but it is stringed together
> > from parts,
> 
> Those "parts" as you call it are the objects. :-)
> 
> > but maybe that is just how you do it in Javascript?
> 
> How you /can/ do it.    You can, if you want, still do it with arrays too. 
> After all, you do not seem to need any (user defined!) functions on any of 
> those objects.    As such you can therefore currently still use the names 
> "object" and "array" interchangably.

No, what i have been after from beginning is that the whole tree "structure" is *ONE* object, not stringed together objects.

In reality it is a texfile for a synth with its banks, presest=intruments, and notes="like drumsamples". I consider it a synth content object. Not four objects that should be stringed together.

Do you understand what i am after?
I do not see why i would have to build the object, from objects.

It is ONE synth object "could be an array holding many synths" not just one, one synth holding banks, each banks holding instruments, some instrument holding named notes.

But it is one object, read in from file not four that i have to string together.


> > Is this also the way others would implemented something
> > like followin pseudo code "structure" in Javascript?
> 
> Definitily not.   For starters, you have "Instrumentindex,Instrumentname" 
> twice in there.  Also, none of the objects (the left-most names) are arrays, 
> they are objects (1).  They /contain/ arrays (the right-most names).

No the (bank,instument,note)(index) is just numbers so it would be a waiste constructing notes for every intruments. Because most do not have note names. And banks are not listed for 0-X they can start bank 47 nest 70 and so on. So it is easier keep the "bankNr, noteNr, instrumentNr out of the array index.

> 
> Furthermore, the XxxxIndex thingies there are properties of the arrays (2), 
> and do not need to be seperatily stored.
> 
> (1) than again, you are still looking at those objects as if they are arrays 
> ...   Whis, in this particular case, they well might be. :-)
> 
> Your "Obj Synth" is special: it currently does not contain anything else 
> than an array called "Bank".  Though it could also contain another property 
> with the name of the play.  "Mozards fitfth" for instance.
> 
> Your 'Bank" object contains two properties: One is its name, and the second 
> an array with "Instrument"s
> 
> Your "Instrument" object contains two properties: One is its name, and the 
> second an array with "Note"s
> 
> Your "Note" object (currently) contains a single property, the notes name.
> 
> (2) you do not need an index to be able to add or loop thru an array. 
> Though I can imagine that its handy when looping thru all the notes.  (for 
> example, to add new element to an array you can use "{arrayname}.push(new 
> item)")
> 
> > Obj. Synth:
> >    //  Prop.
> >    Synth[](InstrumentIndex,InstrumentName,(Bank))
> > [Snip]
> 
> Nope.
> 
> Obj. "Synth":
>   //Prop #1 - "Banks", an array holding zero or more "Bank" objects
> 
>  Obj "Bank":
>   //Prop #1 - "Name", a string
>   //Prop #2 - "Instruments", an array holding zero or more "Instrument" 
> objects
> 
>  Obj "Instrument":
>   //Prop #1 - "Name", a string
>   //Prop #2 - "Notes", an array holding zero or more "Note" objects
> 
>   Obj "Note":
>   //Prop #1 - "Name" - a string indicating a certain note (or 
> sub-instrument).
> 
> > One would like something like a structure explanation for the "object?".
> 
> John G gave you one.  The above is another. But I guess you could also put 
> it down like the below :
> 
>  Synth[Banks[BankName,Instruments[InstrumentName,Notes[NoteName]]]]
> 
> Hope that helps.
> 
> Regards,
> Rudy Wieser

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

#36474

Jonas,

> No, what i have been after from beginning is that the whole
> tree "structure" is *ONE* object, not stringed together objects.

I do not quite understand what the problem with the "stringed together" 
version is.  You can move the whole thing around by moving the root object 
around.   Deleting the root object will automatically delete all child 
objects too (deleting an object will automatically delete all objects it 
references - regardless of them being variables, string, arrays or actual 
objects)

> I consider it a synth content object. Not four objects that
> should be stringed together.

Yes, that is what you should /consider/ it as.   But you /build/ it by 
adding parts-and-bits to it.

> Do you understand what i am after?

Yes.   I think I do.   But I get the feeling that you're standing infront of 
a forrest but do not see it, because all you notice is a bunch of seperate 
trees (no offense intended mind you).

> I do not see why i would have to build the object, from objects.

You do not /have/ to.  You can simply create a single, big (and fixed in all 
but the last dimension) array and use that.

But there are a number of drawbacks connected to such an approach, like 
needing to declare each-and-very area to store the "notes" in big enough to 
store the longest string of notes for /any/ instrument.   Same for the 
"banks" (large enough to store the maximum expected number of instruments 
in).

Thats wil most likely be rather wastefull (just imagine an instrument which 
just plays a few notes - triangles anyone ? :-) ), as well as impossible to 
add more banks, instruments and/or notes than you accounted for while 
creating the big array.

In short, using those objects might look hard, but they give you quite a bit 
of flexibility in handling you "Synth" (with all in it).  And that includes 
to be able to insert or delete banks, instruments and notes at will.

> No the (bank,instument,note)(index) is just numbers so it
> would be a waiste constructing notes for every intruments.

I'm sorry, but I do not see your above description back in the message I 
replied to.   I hower /do/ see this:

>>> Synth[](InstrumentIndex,InstrumentName,(Bank))
...
>>> Instrument[](Instrumentindex,Instrumentname,(Note))

Also, if you do not want to build outof parts that you also cannot build an 
array and than put other arrays into it.     That would be cheating. :-)

> It is ONE synth object "could be an array holding many synths"

Ah.   An object that holds multiple versions of itself ?    And you're 
surprised nobody picked up on that ?

> not just one, one synth holding banks, each banks holding instruments,
> some instrument holding named notes.

But whats the problem ?     Both John and I already showed you that you can 
have a "Banks" array which can contain many "bank" objects (notice that the 
first ends with an "s" (as in multiple), while the latter does not).    And 
we repeated that for/with the "Instruments" array holding "Instrument" 
objects.    You can do *the exact same* for your above problem: A "Synths" 
array holding multiple "Synth" objects.

The new "simple" description would than become:

 Synths[Synth[Banks[BankName,Instruments[InstrumentName,Notes[NoteName]]]]]

Presto!   A "Synths" array holding multiple "Synth" objects which hold ... 
etc, etc,etc.

> And banks are not listed for 0-X they can start bank 47 nest 70 and so on.

1)  Do you think we are mindreaders ?    What you do not tell us we do not 
know.

2) Have you ever thought about naming your variables in a way that they 
actually indicate what they are for ?  Like, I don't know, "BankFirstIndex" 
or "BankIndexOffset" perhaps ?

And if you do it that way, good luck with situations where you use a few 
banks, than a few not, and than again a few.   How are you going to solve 
that ? :-)

As for a possible solution, you can use any associative array instead, with 
the "key" being the 'index number' of the bank, and the "data" belonging to 
that "key"  the bank array/object itself.  That way you only store the banks 
that are truly in use.

Ofcourse, you won't be able to use a simple "by index" anymore.  Than again, 
when you use a "this variable signifies the offset to the first bank" you 
already needed to sprinkle some "magic" over it.  The above (associative 
array method) just makes it a bit different (and quite likely even simpler).

Blimy!   I just realized something: you are probably using the "bank"s to 
solve that above "use a few (instruments -> notes), some not and than again 
some" I spoke of.    Odd. I would have expected it to be applied on the 
notes themselves.  Oh well.

Regards,
Rudy Wieser

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

#36478

On 2019-04-29 8:11 a.m., R.Wieser wrote:
> Jonas,
> 
>> I consider it a synth content object. Not four objects that
>> should be stringed together.
> 
> Yes, that is what you should /consider/ it as.   But you /build/ it by 
> adding parts-and-bits to it.

Very true.

As an analogy, consider a car.  Once it is built, you typically can and
do treat it as a single object.  But when building that same car you
have to consider it as a set of four wheel objects (which in turn are
each built out of tires, rims, ...), plus an engine object (which is a
set of pistons, a crankshaft, ...), and so on.  The use of component
objects simplifies not only building it but also maintaining and
upgrading the bigger object, whether you're talking about a car or software.

In both real life and software, almost every complex object is built out
of simpler component objects.  And it typically nests many levels deep.
There are different levels of abstraction/detail in reality and in
software for very good reasons.  Use them to your advantage.

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

#36480

Den måndag 29 april 2019 kl. 17:15:34 UTC+2 skrev John-Paul Stewart:
> On 2019-04-29 8:11 a.m., R.Wieser wrote:
> > Jonas,
> > 
> >> I consider it a synth content object. Not four objects that
> >> should be stringed together.
> > 
> > Yes, that is what you should /consider/ it as.   But you /build/ it by 
> > adding parts-and-bits to it.
> 
> Very true.
> 
> As an analogy, consider a car.  Once it is built, you typically can and
> do treat it as a single object.  But when building that same car you
> have to consider it as a set of four wheel objects (which in turn are
> each built out of tires, rims, ...), plus an engine object (which is a
> set of pistons, a crankshaft, ...), and so on.  The use of component
> objects simplifies not only building it but also maintaining and
> upgrading the bigger object, whether you're talking about a car or software.
> 
> In both real life and software, almost every complex object is built out
> of simpler component objects.  And it typically nests many levels deep.
> There are different levels of abstraction/detail in reality and in
> software for very good reasons.  Use them to your advantage.

But is not my simple "pseudo code object" also built by parts component objects?
Bank, Instrument, Note that can be expanded? I think there is a stringens in my declaration that javascript lacks, there is probably reasons that the object not declared that way, but from a user perspective my object is a hell lot easier to figure out what is going on.

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

#36488

On 2019-04-29 11:41 a.m., jonas.thornvall@gmail.com wrote:
> Den måndag 29 april 2019 kl. 17:15:34 UTC+2 skrev John-Paul Stewart:
>> On 2019-04-29 8:11 a.m., R.Wieser wrote:
>>> Jonas,
>>>
>>>> I consider it a synth content object. Not four objects that
>>>> should be stringed together.
>>>
>>> Yes, that is what you should /consider/ it as.   But you /build/ it by 
>>> adding parts-and-bits to it.
>>
>> Very true.
>>
>> As an analogy, consider a car.  Once it is built, you typically can and
>> do treat it as a single object.  But when building that same car you
>> have to consider it as a set of four wheel objects (which in turn are
>> each built out of tires, rims, ...), plus an engine object (which is a
>> set of pistons, a crankshaft, ...), and so on.  The use of component
>> objects simplifies not only building it but also maintaining and
>> upgrading the bigger object, whether you're talking about a car or software.
>>
>> In both real life and software, almost every complex object is built out
>> of simpler component objects.  And it typically nests many levels deep.
>> There are different levels of abstraction/detail in reality and in
>> software for very good reasons.  Use them to your advantage.
> 
> But is not my simple "pseudo code object" also built by parts component objects?

I was elaborating on a point made by R.Wieser in response to your
statement (quoted at the top of my previous post) that you "consider it
a synth content object. Not four objects that should be stringed
together."  Now you're saying the exact opposite:  that your object is
composed of other objects.

But my point is that it depends on how you look at it.  Sometimes all
you want is the high-level abstraction of "one object".  At other times
you need the detailed view that it is a bunch of smaller objects.

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

#36491

Den måndag 29 april 2019 kl. 21:16:45 UTC+2 skrev John-Paul Stewart:
> On 2019-04-29 11:41 a.m., jonas.thornvall@gmail.com wrote:
> > Den måndag 29 april 2019 kl. 17:15:34 UTC+2 skrev John-Paul Stewart:
> >> On 2019-04-29 8:11 a.m., R.Wieser wrote:
> >>> Jonas,
> >>>
> >>>> I consider it a synth content object. Not four objects that
> >>>> should be stringed together.
> >>>
> >>> Yes, that is what you should /consider/ it as.   But you /build/ it by 
> >>> adding parts-and-bits to it.
> >>
> >> Very true.
> >>
> >> As an analogy, consider a car.  Once it is built, you typically can and
> >> do treat it as a single object.  But when building that same car you
> >> have to consider it as a set of four wheel objects (which in turn are
> >> each built out of tires, rims, ...), plus an engine object (which is a
> >> set of pistons, a crankshaft, ...), and so on.  The use of component
> >> objects simplifies not only building it but also maintaining and
> >> upgrading the bigger object, whether you're talking about a car or software.
> >>
> >> In both real life and software, almost every complex object is built out
> >> of simpler component objects.  And it typically nests many levels deep.
> >> There are different levels of abstraction/detail in reality and in
> >> software for very good reasons.  Use them to your advantage.
> > 
> > But is not my simple "pseudo code object" also built by parts component objects?
> 
> I was elaborating on a point made by R.Wieser in response to your
> statement (quoted at the top of my previous post) that you "consider it
> a synth content object. Not four objects that should be stringed
> together."  Now you're saying the exact opposite:  that your object is
> composed of other objects.
> 
> But my point is that it depends on how you look at it.  Sometimes all
> you want is the high-level abstraction of "one object".  At other times
> you need the detailed view that it is a bunch of smaller objects.

Of course a thing is built by its parts, i have never questioned that. Those parts are objects "but they are not declared independently of the main object".
That is my point, stringed together vs a declared object structure.

I am really not fond of complicated declaration of objects and doing it in five ways like javascript arrays is just madness.

But if you work upon a "structure" "object", shall read it out, or put something in.

"ISN*T IT NICE IF IT DECLARED HOW IT IS CONSTRUCTED, IN AN EASY READ ENCLOSED STRUCTURE"  ***THAT IS EASILY RECOGNISED**** easily recognised meaning.

Afterall both engineers and architects, leave some sort of schematic over the thingy/building and how they interact.

Apparently javascript try to avoid make schematic to hold the end object hidden from the one reading out the code? So the builders just get parts get some concrete, get some reinforcement, get some paint, get some plumming but no full plan of the building.

You see when you have the plan it is easy to read out information like height, width, lenght and calculate area and how many cubic meters of living space.


Given a plan it is easy to both construct and read out information ***from the object, you plan to build***


Obj. Synth: 
   //  Prop. 
   Synth[](Synthname,(Bank)) 
   //  SubProp/obj. 
   Bank[](BankNr,Bankname,(Instrument)) 
   //  SubProp/obj. 
   Instrument[](InstrumentNr,Instrumentname,(Note)) 
   //  SubProp.     
   Note[](NoteNr, Notename);

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

#36492

Den tisdag 30 april 2019 kl. 00:57:08 UTC+2 skrev jonas.t...@gmail.com:
> Den måndag 29 april 2019 kl. 21:16:45 UTC+2 skrev John-Paul Stewart:
> > On 2019-04-29 11:41 a.m., jonas.thornvall@gmail.com wrote:
> > > Den måndag 29 april 2019 kl. 17:15:34 UTC+2 skrev John-Paul Stewart:
> > >> On 2019-04-29 8:11 a.m., R.Wieser wrote:
> > >>> Jonas,
> > >>>
> > >>>> I consider it a synth content object. Not four objects that
> > >>>> should be stringed together.
> > >>>
> > >>> Yes, that is what you should /consider/ it as.   But you /build/ it by 
> > >>> adding parts-and-bits to it.
> > >>
> > >> Very true.
> > >>
> > >> As an analogy, consider a car.  Once it is built, you typically can and
> > >> do treat it as a single object.  But when building that same car you
> > >> have to consider it as a set of four wheel objects (which in turn are
> > >> each built out of tires, rims, ...), plus an engine object (which is a
> > >> set of pistons, a crankshaft, ...), and so on.  The use of component
> > >> objects simplifies not only building it but also maintaining and
> > >> upgrading the bigger object, whether you're talking about a car or software.
> > >>
> > >> In both real life and software, almost every complex object is built out
> > >> of simpler component objects.  And it typically nests many levels deep.
> > >> There are different levels of abstraction/detail in reality and in
> > >> software for very good reasons.  Use them to your advantage.
> > > 
> > > But is not my simple "pseudo code object" also built by parts component objects?
> > 
> > I was elaborating on a point made by R.Wieser in response to your
> > statement (quoted at the top of my previous post) that you "consider it
> > a synth content object. Not four objects that should be stringed
> > together."  Now you're saying the exact opposite:  that your object is
> > composed of other objects.
> > 
> > But my point is that it depends on how you look at it.  Sometimes all
> > you want is the high-level abstraction of "one object".  At other times
> > you need the detailed view that it is a bunch of smaller objects.
> 
> Of course a thing is built by its parts, i have never questioned that. Those parts are objects "but they are not declared independently of the main object".
> That is my point, stringed together vs a declared object structure.
> 
> I am really not fond of complicated declaration of objects and doing it in five ways like javascript arrays is just madness.
> 
> But if you work upon a "structure" "object", shall read it out, or put something in.
> 
> "ISN*T IT NICE IF IT DECLARED HOW IT IS CONSTRUCTED, IN AN EASY READ ENCLOSED STRUCTURE"  ***THAT IS EASILY RECOGNISED**** easily recognised meaning.
> 
> Afterall both engineers and architects, leave some sort of schematic over the thingy/building and how they interact.
> 
> Apparently javascript try to avoid make schematic to hold the end object hidden from the one reading out the code? So the builders just get parts get some concrete, get some reinforcement, get some paint, get some plumming but no full plan of the building.
> 
> You see when you have the plan it is easy to read out information like height, width, lenght and calculate area and how many cubic meters of living space.
> 
> 
> Given a plan it is easy to both construct and read out information ***from the object, you plan to build***
> 
> 
> Obj. Synth: 
>    //  Prop. 
>    Synth[](Synthname,(Bank)) 
>    //  SubProp/obj. 
>    Bank[](BankNr,Bankname,(Instrument)) 
>    //  SubProp/obj. 
>    Instrument[](InstrumentNr,Instrumentname,(Note)) 
>    //  SubProp.     
>    Note[](NoteNr, Notename);

And isn't there a plan here, javascript object have the look of linked lists
ONEWAY---->
But this structure seem to LINKBACK PARENT<------>CHILD

Well now i really have no idea though if the contructed objects of javascript are linkedback or ONEWAY linked list.

Well from a performance view been playing with graphs, it give tremendous efficiency benefits "when searching" having the linkback vs a oneway lined list.

Because its an open path.

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

#36493

Den tisdag 30 april 2019 kl. 01:08:23 UTC+2 skrev jonas.t...@gmail.com:
> Den tisdag 30 april 2019 kl. 00:57:08 UTC+2 skrev jonas.t...@gmail.com:
> > Den måndag 29 april 2019 kl. 21:16:45 UTC+2 skrev John-Paul Stewart:
> > > On 2019-04-29 11:41 a.m., jonas.thornvall@gmail.com wrote:
> > > > Den måndag 29 april 2019 kl. 17:15:34 UTC+2 skrev John-Paul Stewart:
> > > >> On 2019-04-29 8:11 a.m., R.Wieser wrote:
> > > >>> Jonas,
> > > >>>
> > > >>>> I consider it a synth content object. Not four objects that
> > > >>>> should be stringed together.
> > > >>>
> > > >>> Yes, that is what you should /consider/ it as.   But you /build/ it by 
> > > >>> adding parts-and-bits to it.
> > > >>
> > > >> Very true.
> > > >>
> > > >> As an analogy, consider a car.  Once it is built, you typically can and
> > > >> do treat it as a single object.  But when building that same car you
> > > >> have to consider it as a set of four wheel objects (which in turn are
> > > >> each built out of tires, rims, ...), plus an engine object (which is a
> > > >> set of pistons, a crankshaft, ...), and so on.  The use of component
> > > >> objects simplifies not only building it but also maintaining and
> > > >> upgrading the bigger object, whether you're talking about a car or software.
> > > >>
> > > >> In both real life and software, almost every complex object is built out
> > > >> of simpler component objects.  And it typically nests many levels deep.
> > > >> There are different levels of abstraction/detail in reality and in
> > > >> software for very good reasons.  Use them to your advantage.
> > > > 
> > > > But is not my simple "pseudo code object" also built by parts component objects?
> > > 
> > > I was elaborating on a point made by R.Wieser in response to your
> > > statement (quoted at the top of my previous post) that you "consider it
> > > a synth content object. Not four objects that should be stringed
> > > together."  Now you're saying the exact opposite:  that your object is
> > > composed of other objects.
> > > 
> > > But my point is that it depends on how you look at it.  Sometimes all
> > > you want is the high-level abstraction of "one object".  At other times
> > > you need the detailed view that it is a bunch of smaller objects.
> > 
> > Of course a thing is built by its parts, i have never questioned that. Those parts are objects "but they are not declared independently of the main object".
> > That is my point, stringed together vs a declared object structure.
> > 
> > I am really not fond of complicated declaration of objects and doing it in five ways like javascript arrays is just madness.
> > 
> > But if you work upon a "structure" "object", shall read it out, or put something in.
> > 
> > "ISN*T IT NICE IF IT DECLARED HOW IT IS CONSTRUCTED, IN AN EASY READ ENCLOSED STRUCTURE"  ***THAT IS EASILY RECOGNISED**** easily recognised meaning.
> > 
> > Afterall both engineers and architects, leave some sort of schematic over the thingy/building and how they interact.
> > 
> > Apparently javascript try to avoid make schematic to hold the end object hidden from the one reading out the code? So the builders just get parts get some concrete, get some reinforcement, get some paint, get some plumming but no full plan of the building.
> > 
> > You see when you have the plan it is easy to read out information like height, width, lenght and calculate area and how many cubic meters of living space.
> > 
> > 
> > Given a plan it is easy to both construct and read out information ***from the object, you plan to build***
> > 
> > 
> > Obj. Synth: 
> >    //  Prop. 
> >    Synth[](Synthname,(Bank)) 
> >    //  SubProp/obj. 
> >    Bank[](BankNr,Bankname,(Instrument)) 
> >    //  SubProp/obj. 
> >    Instrument[](InstrumentNr,Instrumentname,(Note)) 
> >    //  SubProp.     
> >    Note[](NoteNr, Notename);
> 
> And isn't there a plan here, javascript object have the look of linked lists
> ONEWAY---->
> But this structure seem to LINKBACK PARENT<------>CHILD
> 
> Well now i really have no idea though if the contructed objects of javascript are linkedback or ONEWAY linked list.
> 
> Well from a performance view been playing with graphs, it give tremendous efficiency benefits "when searching" having the linkback vs a oneway lined list.
> 
> Because its an open path.

https://jonasth.000webhostapp.com/

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

#36483

On Monday, 29 April 2019 17:15:34 UTC+2, John-Paul Stewart  wrote:
> On 2019-04-29 8:11 a.m., R.Wieser wrote:
> > Jonas,
> > 
> >> I consider it a synth content object. Not four objects that
> >> should be stringed together.
> > 
> > Yes, that is what you should /consider/ it as.   But you /build/ it by 
> > adding parts-and-bits to it.
> 
> Very true.
> 
> As an analogy, consider a car.  Once it is built, you typically can and
> do treat it as a single object.  But when building that same car you
> have to consider it as a set of four wheel objects (which in turn are
> each built out of tires, rims, ...), plus an engine object (which is a
> set of pistons, a crankshaft, ...), and so on.  The use of component
> objects simplifies not only building it but also maintaining and
> upgrading the bigger object, whether you're talking about a car or software.
> 
> In both real life and software, almost every complex object is built out
> of simpler component objects.  And it typically nests many levels deep.
> There are different levels of abstraction/detail in reality and in
> software for very good reasons.  Use them to your advantage.

What another pile of mainstream false philosophy and crap,
Mr John-Paul Sartre now...

You guys do deserve just oblivion.

*Plonk*

Julio

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

#36479

Den måndag 29 april 2019 kl. 14:11:28 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > No, what i have been after from beginning is that the whole
> > tree "structure" is *ONE* object, not stringed together objects.
> 
> I do not quite understand what the problem with the "stringed together" 
> version is.  You can move the whole thing around by moving the root object 
> around.   Deleting the root object will automatically delete all child 
> objects too (deleting an object will automatically delete all objects it 
> references - regardless of them being variables, string, arrays or actual 
> objects)
> 
> > I consider it a synth content object. Not four objects that
> > should be stringed together.
> 
> Yes, that is what you should /consider/ it as.   But you /build/ it by 
> adding parts-and-bits to it.
> 
> > Do you understand what i am after?
> 
> Yes.   I think I do.   But I get the feeling that you're standing infront of 
> a forrest but do not see it, because all you notice is a bunch of seperate 
> trees (no offense intended mind you).
> 
> > I do not see why i would have to build the object, from objects.
> 
> You do not /have/ to.  You can simply create a single, big (and fixed in all 
> but the last dimension) array and use that.
> 
> But there are a number of drawbacks connected to such an approach, like 
> needing to declare each-and-very area to store the "notes" in big enough to 
> store the longest string of notes for /any/ instrument.   Same for the 
> "banks" (large enough to store the maximum expected number of instruments 
> in).
> 
> Thats wil most likely be rather wastefull (just imagine an instrument which 
> just plays a few notes - triangles anyone ? :-) ), as well as impossible to 
> add more banks, instruments and/or notes than you accounted for while 
> creating the big array.
> 
> In short, using those objects might look hard, but they give you quite a bit 
> of flexibility in handling you "Synth" (with all in it).  And that includes 
> to be able to insert or delete banks, instruments and notes at will.
> 
> > No the (bank,instument,note)(index) is just numbers so it
> > would be a waiste constructing notes for every intruments.
> 
> I'm sorry, but I do not see your above description back in the message I 
> replied to.   I hower /do/ see this:
> 
> >>> Synth[](InstrumentIndex,InstrumentName,(Bank))
> ...
> >>> Instrument[](Instrumentindex,Instrumentname,(Note))
> 
> Also, if you do not want to build outof parts that you also cannot build an 
> array and than put other arrays into it.     That would be cheating. :-)
> 
> > It is ONE synth object "could be an array holding many synths"
> 
> Ah.   An object that holds multiple versions of itself ?    And you're 
> surprised nobody picked up on that ?
> 
> > not just one, one synth holding banks, each banks holding instruments,
> > some instrument holding named notes.
> 
> But whats the problem ?     Both John and I already showed you that you can 
> have a "Banks" array which can contain many "bank" objects (notice that the 
> first ends with an "s" (as in multiple), while the latter does not).    And 
> we repeated that for/with the "Instruments" array holding "Instrument" 
> objects.    You can do *the exact same* for your above problem: A "Synths" 
> array holding multiple "Synth" objects.
> 
> The new "simple" description would than become:
> 
>  Synths[Synth[Banks[BankName,Instruments[InstrumentName,Notes[NoteName]]]]]
> 
> Presto!   A "Synths" array holding multiple "Synth" objects which hold ... 
> etc, etc,etc.
> 
> > And banks are not listed for 0-X they can start bank 47 nest 70 and so on.
> 
> 1)  Do you think we are mindreaders ?    What you do not tell us we do not 
> know.
> 
> 2) Have you ever thought about naming your variables in a way that they 
> actually indicate what they are for ?  Like, I don't know, "BankFirstIndex" 
> or "BankIndexOffset" perhaps ?
> 
> And if you do it that way, good luck with situations where you use a few 
> banks, than a few not, and than again a few.   How are you going to solve 
> that ? :-)
> 
> As for a possible solution, you can use any associative array instead, with 
> the "key" being the 'index number' of the bank, and the "data" belonging to 
> that "key"  the bank array/object itself.  That way you only store the banks 
> that are truly in use.
> 
> Ofcourse, you won't be able to use a simple "by index" anymore.  Than again, 
> when you use a "this variable signifies the offset to the first bank" you 
> already needed to sprinkle some "magic" over it.  The above (associative 
> array method) just makes it a bit different (and quite likely even simpler).
> 
> Blimy!   I just realized something: you are probably using the "bank"s to 
> solve that above "use a few (instruments -> notes), some not and than again 
> some" I spoke of.    Odd. I would have expected it to be applied on the 
> notes themselves.  Oh well.

Well it is all a hierarchy of arrays, and as you say use "the actual banknumbers, the actual instrumentnumbers, and notenumbers" by having them in array index you will indeed make some sort of monster. So it is better they are properties. Because then you only fill array slots actually containing something. And you do not have to search for them in an array full of null values.

No i understand the Javascript approach now and have no problem with it. But it is not *selfevident* that is the way to "declare" the object. Because for someone reading the code it become strange indeed. If the object had a simpler structure like i proposed it is easier to take in what that structure is.

Now that object become a bit vague for someone who read, when you string together. And the biggest problem people like me just do not understand howto create such, because there is no examples of such objects to find in documentation. So it become guesswork, no i would never had thought you made the synth object by string together object, i thought it was a single declaration and of a structure of sort. 

So all is well i do get it, what i say is people can not figure it out on their own howto create that structure? object?, because they will try to make an object like me. I would prefered  it the other way around, but that is taste i guess.

That is what i mean it is a bit vague what it is, i am still not sure if it is a tree structure or an object. It become so vague when you string things together.

> 
> Regards,
> Rudy Wieser

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

#36433

jonas.thornvall@gmail.com wrote on 26 Apr 2019 in comp.lang.javascript:

> either i am  fucking stupid 

Worth considering as a valid alternative, Jonas.

> and i really tried to figure it out by myself 

Wouldn't "either" need a "or" clause to be valid in EnglishLint?

> "because i am totally clueless ...

Unmatched ", is this a quote?

Would, however, be a good argument for the top premise.

===============

No, Jonas, 
doing something stupid does not imply you are stupid.

You are NOT fuckingly so!

Asserting such because you fail to accomplish something 
could also mean you miss the basic skills to understand a method,
and you would need to go back to studying the basics.


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

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

#36426

Den torsdag 25 april 2019 kl. 19:37:51 UTC+2 skrev John G Harris:
> On Thu, 25 Apr 2019 09:12:15 -0700 (PDT), groovee@cyberdude.com wrote:
> 
> >On Thursday, 25 April 2019 14:46:25 UTC+5:30, jonas.t...@gmail.com  wrote:
> >
> >> 
> >> The fucking syntax of javascript objects is unbearable and uncomprehensible, the fucker who came up with it must be clinically insane...
> >
> >
> >I didn't read all of your post, but - I have often felt the exact same! :) WTF is "document.getElementById("blah").addEventListener" ANYWAY? You have to do THAT MUCH to register a simple event handler?
> 
> How then would you say which part of the document that event handler
> should be associated with?
> 
> 
> >....and I TILL DATE (and I've been battling with JS for a while now) don't understand what TWO DOTS (as above) mean - to me, it's incomprehensible :(
> 
> You want to do something to the b part of a. One notation to get to it
> is a<b>; another is  b of a ; a more popular one is a.b .
> 
> Obviously, if b has a c part you get to it by doing a.b.c . Or would
> you prefer c of b of a ?
> 
>   John

A path chosen is a path chosen John.
But of course.

EV.mouseOut(document.blah) do {alert("i get this");} 

Would been hell much easier to learn ***and read***

There is something very unnatural inorganic about the javascript syntax, maybe even illogical. 

I guess it is because it has a large theoretical groundwork and the implementation coming out of university theories. So the guys that implement it are tied up, to some foundational work they follow. 

But honestly since the stringhandling methods, which was excellent the syntax gone to shit and incomprehensible nonsesense.

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

#36427

Den fredag 26 april 2019 kl. 09:25:14 UTC+2 skrev jonas.t...@gmail.com:
> Den torsdag 25 april 2019 kl. 19:37:51 UTC+2 skrev John G Harris:
> > On Thu, 25 Apr 2019 09:12:15 -0700 (PDT), groovee@cyberdude.com wrote:
> > 
> > >On Thursday, 25 April 2019 14:46:25 UTC+5:30, jonas.t...@gmail.com  wrote:
> > >
> > >> 
> > >> The fucking syntax of javascript objects is unbearable and uncomprehensible, the fucker who came up with it must be clinically insane...
> > >
> > >
> > >I didn't read all of your post, but - I have often felt the exact same! :) WTF is "document.getElementById("blah").addEventListener" ANYWAY? You have to do THAT MUCH to register a simple event handler?
> > 
> > How then would you say which part of the document that event handler
> > should be associated with?
> > 
> > 
> > >....and I TILL DATE (and I've been battling with JS for a while now) don't understand what TWO DOTS (as above) mean - to me, it's incomprehensible :(
> > 
> > You want to do something to the b part of a. One notation to get to it
> > is a<b>; another is  b of a ; a more popular one is a.b .
> > 
> > Obviously, if b has a c part you get to it by doing a.b.c . Or would
> > you prefer c of b of a ?
> > 
> >   John
> 
> A path chosen is a path chosen John.
> But of course.
> 
> EV.mouseOut(document.blah) do {alert("i get this");} 
> 
> Would been hell much easier to learn ***and read***
> 
> There is something very unnatural inorganic about the javascript syntax, maybe even illogical. 
> 
> I guess it is because it has a large theoretical groundwork and the implementation coming out of university theories. So the guys that implement it are tied up, to some foundational work they follow. 
> 
> But honestly since the stringhandling methods, which was excellent the syntax gone to shit and incomprehensible nonsesense.

If you wanted you could name the EV

A.EV.mouseOut(document.blah)

And then A.On()
         A.Off()

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

#36428

Den fredag 26 april 2019 kl. 09:25:14 UTC+2 skrev jonas.t...@gmail.com:
> Den torsdag 25 april 2019 kl. 19:37:51 UTC+2 skrev John G Harris:
> > On Thu, 25 Apr 2019 09:12:15 -0700 (PDT), groovee@cyberdude.com wrote:
> > 
> > >On Thursday, 25 April 2019 14:46:25 UTC+5:30, jonas.t...@gmail.com  wrote:
> > >
> > >> 
> > >> The fucking syntax of javascript objects is unbearable and uncomprehensible, the fucker who came up with it must be clinically insane...
> > >
> > >
> > >I didn't read all of your post, but - I have often felt the exact same! :) WTF is "document.getElementById("blah").addEventListener" ANYWAY? You have to do THAT MUCH to register a simple event handler?
> > 
> > How then would you say which part of the document that event handler
> > should be associated with?
> > 
> > 
> > >....and I TILL DATE (and I've been battling with JS for a while now) don't understand what TWO DOTS (as above) mean - to me, it's incomprehensible :(
> > 
> > You want to do something to the b part of a. One notation to get to it
> > is a<b>; another is  b of a ; a more popular one is a.b .
> > 
> > Obviously, if b has a c part you get to it by doing a.b.c . Or would
> > you prefer c of b of a ?
> > 
> >   John
> 
> A path chosen is a path chosen John.
> But of course.
> 
> EV.mouseOut(document.blah) do {alert("i get this");} 
> 
> Would been hell much easier to learn ***and read***
> 
> There is something very unnatural inorganic about the javascript syntax, maybe even illogical. 
> 
> I guess it is because it has a large theoretical groundwork and the implementation coming out of university theories. So the guys that implement it are tied up, to some foundational work they follow. 
> 
> But honestly since the stringhandling methods, which was excellent the syntax gone to shit and incomprehensible nonsesense.

do is very nice, it would make it easier for anyone reading syntax and learn to read logical statements. And for people beginning programming learning about abstraction it is vital. It transforms a bunch on nonsense "semantical symbols" into meaningful statements.

I love DO, it make sense to me.

If(A<B) do B-C. //Yeah that would do the subtraction on B.
If(A>B) call EASY().
copy (B to C).

EASY: Alert"There is something beautiful coming out of simplicity, think how fast people would be able to learn programming in script languages, but i bet the blip bloppers are terrified".


Print screen position X,Y "CAT".
X.OutputField position X,Y "Was not my cat".
Wait 20 sek.
X "Now it yours".
Revoke X, Alert




)

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

#36435

On Thursday, 25 April 2019 23:07:51 UTC+5:30, John G Harris  wrote:

> How then would you say which part of the document that event handler
> should be associated with?
> 


registerHandler(blah, foo), where blah is something in the page, and foo is the function that'll be called.




> You want to do something to the b part of a. One notation to get to it
> is a<b>; another is  b of a ; a more popular one is a.b .
> 
> Obviously, if b has a c part you get to it by doing a.b.c . Or would
> you prefer c of b of a ?
> 

How in God's name is "addEventListener" a *PART* of document.getElementById??!!

document.getElementById GETS something from the page, how the hell is it *returning an object*, and why??? Why is that necessary and why do it that way?



And in fact I don't understand what "document.getElementById" is in the FIRST place!!
The document, ie. the HTML page contains ELEMENTS, not a function called "getElementById"...??!!
This is what it SHOULD have been:

registerHandler(document.blah, foo); (IF at all "document" is required!)




Well, I guess MY poor little brain can't match Brendan Eich's :) 

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

#36438

On 2019-04-26, groovee@cyberdude.com <groovee@cyberdude.com> wrote:
> How in God's name is "addEventListener" a *PART* of
> document.getElementById??!!

It isn't. It's a method of the object that's returned by
document.getElementById().

> document.getElementById GETS something from the page, how the hell
> is it *returning an object*, and why???

The object *is* the thing returned from the page. What would you
expect getElementById() to return?

> Why is that necessary and why do it that way?

Because it's the obviously correct and sensible way to do it?

> And in fact I don't understand what "document.getElementById" is in
> the FIRST place!! The document, ie. the HTML page contains ELEMENTS,
> not a function called "getElementById"...??!!

It contains both.

> Well, I guess MY poor little brain can't match Brendan Eich's :) 

He only had 10 days in which to create JavaScript, he can be forgiven
for some of its vagaries...

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

#36444

Jon Ribbens wrote:
> On 2019-04-26, groovee@cyberdude.com <groovee@cyberdude.com> wrote:
>> How in God's name is "addEventListener" a *PART* of
>> document.getElementById??!!
> 
> It isn't. It's a method of the object that's returned by
> document.getElementById().

Almost correct:

>> document.getElementById GETS something from the page, how the hell
>> is it *returning an object*, and why???
> 
> The object *is* the thing returned from the page.

Only loosely speaking.  What is returned is a *reference* to an object, and
that reference is being *resolved* when the dot property accessor for the
method is being evaluated.

> What would you expect getElementById() to return?

If there is no element with that ID, it is supposed to return the “null”
value :)

>> And in fact I don't understand what "document.getElementById" is in
>> the FIRST place!! The document, ie. the HTML page contains ELEMENTS,
>> not a function called "getElementById"...??!!
> 
> It contains both.

(There are no “HTML pages”.)

No, instead the *method* “getElementById” is provided by an *implementation*
of DOM *interfaces* that is in turn provided by the *layout engine*.

The HTML document is *represented* in the DOM implementation (for historical
and practical reasons) by an object referable by the identifier “document”
(because there is an object in the scope chain that has a corresponding
property of that “name” whose value *is* the reference to the former object).

>> Well, I guess MY poor little brain can't match Brendan Eich's :) 
> 
> He only had 10 days in which to create JavaScript, he can be forgiven
> for some of its vagaries...

Brendan Eich was NOT responsible for the *W3C* DOM (but probably for its
predecessor, the Netscape DOM).  One must learn to mentally *separate* the
programming languages and the (W3C) DOM (that can be used with them); the
other way lies madness.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#36455

On Fri, 26 Apr 2019 23:23:08 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>What is returned is a *reference* to an object
  <snip>

Thomas, please stop insisting on a bad implementation. You are
committing a disservice to the community.

In the hope that you might understand this time, I'll repeat what I
wrote a few months ago :


A sensible designer would listen to his colleagues who say "My 
grandad did it this way and so did his grandad, and so did his 
grandad afore him, so we MUST do it this way. The sensible designer
would then think for a few minutes to see if there is another way
that is better. 

And there is! Instead of Values holding a reference
to an Object, make each variable and property hold a reference to its 
Value. Now there is no problem with variables that have the same 
Value. Better still, it solves an annoying performance problem with 
no extra code at all : very long primitive strings can now be passed 
to functions without having to copy them. The Value is shared 
instead.

  John

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web