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

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

Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern

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

Contents

  Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern chrisrussell41@gmail.com - 2013-11-11 14:06 -0800
    Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-12 00:31 +0100
      Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern chrisrussell41@gmail.com - 2013-11-11 22:15 -0800
        Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-12 12:45 +0100
          Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Chris Russell <chrisrussell41@gmail.com> - 2013-11-12 14:26 -0800
            Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-15 14:14 +0100
        Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-12 21:53 +0000
          Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Christoph Michael Becker <cmbecker69@arcor.de> - 2013-11-12 23:33 +0100
            Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-13 00:17 +0100
              Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-13 14:56 +0000
            Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern John Harris <niam@jghnorth.org.uk.invalid> - 2013-11-13 15:02 +0000
              Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Chris Russell <chrisrussell41@gmail.com> - 2013-11-13 11:25 -0800
                Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Chris Russell <chrisrussell41@gmail.com> - 2013-11-13 11:45 -0800
                  Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-15 01:56 +0100
      Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-11-17 02:21 +0100
        Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Chris Russell <chrisrussell41@gmail.com> - 2013-11-19 10:28 -0800
          Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2013-11-20 01:41 +0100
            Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern Chris Russell <chrisrussell41@gmail.com> - 2013-11-24 15:16 -0800

#21970 — Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern

Hello, JavaScripters.

I have been working on a new JavaScript library called ONMjs (Object Namespace Manager) that's intended to dramatically simplify the task of writing complex single-page HTML 5 applications (e.g. interactive visualizations, hierarchical forms, basically anything with a non-trivial client-side data/meta-data model).

ONMjs is based on a design pattern called Model-Store-Observe-Feedback-Signal (MSOFS) that derives from and combines concepts from a number of popular design and implementation patterns in a unique way. 

Simple JSFIDDLE demonstrating the basic MSOFS pattern: http://jsfiddle.net/Encapsule/EXB4M/

Blog post discussing MSOFS and the MVC pattern:
http://blog.chrisrussell.net/2013/11/08/todomvc-model-view-whatever-and-msofs/

In a nutshell, ONMjs allows you declare a data model via a simple JavaScript object, and then leverage the provided generic run-time classes to manufacture and manage resource identifier _addressable_ instances of your data, and coordinate the actions of your various subsystems on data instances via an implementation of the observer pattern.

The core ONMjs classes are dependency-free JavaScript (compiled from CoffeeScript sources), and are intended to be used with your favorite library/framework for implementing your views and implementation subsystems. I have also published a small collection of generic view classes based on the Knockout.js MVVM framework that demonstrate one possible way of integrating ONMjs with other popular frameworks.

Library sources are live on GitHub (MIT license) and documentation for the five (5) core JavaScript classes that comprise the library is now complete. 

Here are some links:

Sources and documentation: https://github.com/encapsule/onmjs
Download: http://onmjs.encapsule.org/

I hope you find this topic interesting and would very much appreciate your feedback, and questions on this work.

Regards, ChrisRus

[toc] | [next] | [standalone]

#21972

chrisrussell41@gmail.com wrote:
^^^^^^^^^^^^^^^^^^^^^^^^
Please fix.

> In a nutshell, ONMjs allows you declare a data model via a simple
> JavaScript object, and then leverage the provided generic run-time classes
> to manufacture and manage resource identifier _addressable_ instances of
> your data, and coordinate the actions of your various subsystems on data
> instances via an implementation of the observer pattern.
> 
> The core ONMjs classes are dependency-free JavaScript

There are no classes in production-quality JavaScript yet, and don't get me 
started on your use of “JavaScript”.  <http://PointedEars.de/es-matrix>

Contrary to your statement, using the observer pattern, which I would 
consider core functionality as described above, you are using jQuery, and 
whatnot which also does not bode well for the rest.

> (compiled from CoffeeScript sources),

“generated bloat code that cannot be debugged”

I could not find any *relevant* *ECMAScript-based* code written by *you* 
that would be on-topic here.

-- 
PointedEars

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

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

#21982

This seems rather harsh feedback in response to my post but I can roll with it as I'm learning and there's a lot to be learned from negative feedback.

> http://pointedears.de/scripts/test/es-matrix/

Interesting matrix you've created. I'll need to parse further in order to identify just specifically which column my work falls in.

> There are no classes in production-quality JavaScript yet

I made no such assertion. Be kind to a C++ programmer who is making an effort to improve their knowledge and broaden their horizons. I know it's not perfect and can be improved. Specific criticisms would be helpful.

> you are using jQuery

... as a convenience in JSFIDDLE examples, yes. Not as a dependency of the core classes that do not leverage JQuery (or any other library).

> Contrary to your statement, using the observer pattern, which I would consider core functionality as described above <snip>

I don't follow. The ONMjs.Store class provides register/unregisterObserver methods and a documented API for the callbacks. Would you explain your point further please.

> I could not find any *relevant* *ECMAScript-based* code written by *you* that would be on-topic here.

http://onmjs.encapsule.org/stage/js/core/

Notwithstanding your objection to authoring in CoffeeScript, the contents of that directory is original. I'm not saying it's perfect, but it works pretty well. Enough so that I would write and ask you folks for some feedback.

Thanks, Chris




On Monday, November 11, 2013 3:31:24 PM UTC-8, Thomas 'PointedEars' Lahn wrote:
> chrisrussell41@gmail.com wrote:
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Please fix.
> 
> 
> 
> > In a nutshell, ONMjs allows you declare a data model via a simple
> 
> > JavaScript object, and then leverage the provided generic run-time classes
> 
> > to manufacture and manage resource identifier _addressable_ instances of
> 
> > your data, and coordinate the actions of your various subsystems on data
> 
> > instances via an implementation of the observer pattern.
> 
> > 
> 
> > The core ONMjs classes are dependency-free JavaScript
> 
> 
> 
> There are no classes in production-quality JavaScript yet, and don't get me 
> 
> started on your use of “JavaScript”.  <http://PointedEars.de/es-matrix>
> 
> 
> 
> Contrary to your statement, using the observer pattern, which I would 
> 
> consider core functionality as described above, you are using jQuery, and 
> 
> whatnot which also does not bode well for the rest.
> 
> 
> 
> > (compiled from CoffeeScript sources),
> 
> 
> 
> “generated bloat code that cannot be debugged”
> 
> 
> 
> I could not find any *relevant* *ECMAScript-based* code written by *you* 
> 
> that would be on-topic here.
> 
> 
> 
> -- 
> 
> PointedEars
> 
> 
> 
> Twitter: @PointedEars2
> 
> Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#21983

chrisrussell41@gmail.com wrote:
^^^^^^^^^^^^^^^^^^^^^^^^
This is Usenet.  Your real name should go there.

[Added attribution line; please do not remove next time]

> Thomas 'PointedEars' Lahn wrote:
>> http://pointedears.de/scripts/test/es-matrix/
> 
> Interesting matrix you've created. I'll need to parse further in order to
> identify just specifically which column my work falls in.

All of them, I presume.

CoffeeScript generates ECMAScript-based code (and each column of the feature 
table deals with one ECMAScript implementation, all of which should be 
capable in their current version to parse the code), but not necessarily 
good one.

In fact, the code you have generated suggests what I had suspected for a 
long time: that the code generated by it is very bad.  See below.
 
>>> The core ONMjs classes are dependency-free JavaScript
>> There are no classes in production-quality JavaScript yet
> 
> I made no such assertion.

Yes you did.  I have restored the quote above.

By “production-quality JavaScript” I mean a *JavaScript[tm]* script *engine* 
that is ready for use in production.  There has been an implementation of 
ECMAScript Edition 4, which introduced classes, JavaScript 2.0 
(“Epimetheus”), before it was abandoned, but it never was ready for use in 
production.  All other ECMAScript implementations are not (called (only)) 
JavaScript.  There is Microsoft JScript .NET for ASP .NET on IIS that does 
have classes, and there is ActionScript 2+ for Macromedia/Adobe Flash that 
does.

> Be kind to a C++ programmer who is making an effort to improve their
> knowledge and broaden their horizons. I know it's not perfect and can be
> improved. Specific criticisms would be helpful.

JavaScript[tm] is but one of many implementations of ECMAScript.  Client-
side ECMAScript implementations, with the exception of ActionScript 2+, are 
object-oriented languages that use *prototype*-based, not class-based, 
inheritance: Objects inherit properties from other objects, through a 
mechanism called “prototype chain”.

Nevertheless, objects created using a constructor, or a constructor whose 
prototype object (the object that its “prototype” property refers to) is in 
the prototype chain of the prototype object of another constructor, are 
called “instances” of that constructor in the Specification (hence the 
“instanceof” operator borrowed from Java).  Constructors are (WLOG) 
functions, and functions are first-class objects, (WLOG) Function instances.
 
>> you are using jQuery
> 
> ... as a convenience in JSFIDDLE examples, yes. Not as a dependency of the
> core classes that do not leverage JQuery (or any other library).

OK.  I found the following in your repository description confusing:

| Observer dependencies: JQuery, D3js, Knockout.js
 
>> Contrary to your statement, using the observer pattern, which I would
>> consider core functionality as described above <snip>
> 
> I don't follow. The ONMjs.Store class provides register/unregisterObserver
> methods and a documented API for the callbacks. Would you explain your
> point further please.
 
You have snipped my answer so that the quote does not contain my point.
But assuming that your previous statement is true, it is moot now.

>> I could not find any *relevant* *ECMAScript-based* code written by *you*
>> that would be on-topic here.
> 
> http://onmjs.encapsule.org/stage/js/core/

Thanks.
 
> Notwithstanding your objection to authoring in CoffeeScript, the contents
> of that directory is original. I'm not saying it's perfect, but it works
                                                                  ^^^^^^^^
> pretty well.
  ^^^^^^^^^^^^
Sigh. [psf 10.1]

> Enough so that I would write and ask you folks for some feedback.

It is worse than I initially expected.  Let us just look at the generated
ONMjs-core-model.js (which already is 21K uncompressed):

- You do *a lot* of pointless operations (that also add to the footprint). 
  While

  | var ONMjs, namespaceEncapsule;
  | 
  | namespaceEncapsule = (typeof Encapsule !== "undefined" && Encapsule
  |   !== null) && Encapsule || (this.Encapsule = {});

  is somewhat forgivable –

    var namespaceEncapsule =
      (typeof Encapsule !== "undefined" && Encapsule !== null)
        ? Encapsule
        : (this.Encapsule = {});

  would have been clearer, although “this.Encapsule = {}” is unnecessary
  if you return the reference to the object –

  | Encapsule.code.lib = (Encapsule.code.lib != null) && Encapsule.code.lib
  |   || (this.Encapsule.code.lib = {});

  is not.

    if (!Encapsule.code.lib)
    {
      Encapsule.code.lib = (this.Encapsule.code.lib = {});
    }

  is equivalent, more efficient, clearer code.  (But the double assignment
  is still bogus.)

- You have functions with more than 5 formal parameters:

  | buildOMDescriptorFromLayout = function(ONMD_, path_, parentDescriptor_,
  | componentDescriptor_, parentPathIdVector_,
  | parentPathExtensionPointIdVector_) {
  |   …
  | }

  No function should have more than 5 formal parameters because few people
  will remember them.  Use one Object-typed parameter if you cannot refactor
  top-down.

- You do type-converting comparisons against “null” for no obvious reason:

  | if (!((ONMD_ != null) && ONMD_)) {

    if (!ONMD_)
    {
      …
    }

  is equivalent, more efficient, and clearer.  There are no “null pointer
  accesses” that would need to be avoided in these languages: “null” is the
  sole value of the Null type, and type conversion (here: to Boolean) is
  implicit (unless prevented by strict comparison):

  | >>> var a = [[], [1], false, true, new Date(), function () {}, Math, -1,
  | 0, 1, NaN, -Infinity, Infinity, null, {}, {x: 42}, /(?:)/, /x/, "", "x",
  | void 0];
  | for (var i = a.length; i--;)
  | {
  |   var e = a[i];
  |   console.log(!((e != null && e)), !e);
  | }
  | 
  |     true true
  |     false false
  |     true true
  | (4) false false
  |     true true
  | (2) false false
  |     true true
  |     false false
  |     true true
  | (5) false false
  |     true true
  | (2) false false
  | ← undefined

  The only thing you do need to avoid to access *standalone identifiers*
  directly that may not have been declared (which is why the “typeof”
  operation has been used above).

- You throw unformatted strings for exceptions:

  | throw "Missing object model layout object input parameter! If you
  | specified the namespace declaration via object reference, check the
  | validity of the reference.";

  In order to determine *which* exception was thrown, the caller would have
  to do something error-prone like

    try
    {
      yourFunction();
    }
    catch (e)
    {
      if (e.message == "Missing object model layout object input …")
      {
        // …
      }
    }

  when, if you had written, for example,

    throw new ONMjs.InvalidArgumentError("…");

  they could have written

    try
    {
      yourFunction();
    }
    catch (e)
    {
      if (e && e.constructor == ONMjs.InvalidArgumentError)
      {
        // console.log(e.message);
      }
      else
      {
        throw e;
      }
    }

  or

    try
    {
      yourFunction();
    }
    catch (e)
    {
      if (e instanceof ONMjs.InvalidArgumentError)
      {
        // console.log(e.message);
      }
      else
      {
        throw e;
      }
    }

  or in JavaScript 1.5+ even

    try
    {
      yourFunction();
    }
    catch (e if e instanceof ONMjs.InvalidArgumentError)
    {
      // console.log(e.message);      
    }

- All your methods are instance methods even when they could have been
  inherited from a prototype object which would have saved precious heap
  per instance:

  | this.getNamespaceDescriptorFromPath = function(path_) {
  |   try {
  |     return 
  |     
_this.getNamespaceDescriptorFromPathId(_this.getPathIdFromPath(path_));
  |   } catch (exception) {
  |     throw 
"ONMjs.implementation.ModelDetails.getNamespaceDescriptorFromPath failure: " 
+ exception;
  |   }
  | };

  “_this” is merely your alias for “this” in the same execution context –

| var buildOMDescriptorFromLayout,
|   _this = this;
| 

  – so what's the point?

- None of this code is inline-commented and lines are far too long.
  It *is* hard to debug.

And so on.

I do not care if this nonsense was generated by CoffeeScript or if it was so 
in your original design.  All I do care about is that the outcome is bad 
code.

What we see here is the result of the common fallacy of overgeneralization, 
the attempt at a one-size-fits-all solution that is supposed to make things 
easier (but in the end doesn't).  The record shows that it is often better 
to write code specific to a small purpose, and then combine specific code 
for a larger purpose – transferring the “one tool for one purpose” approach 
to general programming if you will.

See also: 
<http://en.wikipedia.org/wiki/Framework_(computer_science)#Rationale>

> [Top post]

Please don't.

<http://PointedEars.de/faq>

-- 
PointedEars

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

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

#21987

> This is Usenet.  Your real name should go there.
Right. I usually use gmane.org via Thunderbird client but this list doesn't seem to be mirrored so using Google Groups w/out tweaking settings. Should be corrected now.

I want to thank you for taking the time to look at my code and comment, Thomas. You could have just as well ignored my post.

I've read through your latest reply and understand most of what you've said. In particular your objection to using instance vs. prototype methods is very helpful. As well, the suggestion to _not_ throw raw strings for errors is good and I understand the rationale. Also, there are a number of other inefficiencies that you point out. Some of these I know about but haven't taken the time to address. Some are issues I had not considered. As a learning exercise, and because I actually do care that this code is well-written and efficient, I'm going to file issues against myself work to make the necessary improvements.

> CoffeeScript
It may be that I've misunderstood or misused CoffeeScript resulting in functional, but badly structured code. For example, I can likely improve some of the loop constructs by leveraging CoffeeScript comprehensions vs. for loops in some cases. Likely other examples as well. I'll have to work through the details.


But wait... Why bother? You made some observations that call into question the viability and quality of the overall design of the library (vs. implementation idioms that I've leveraged that aren't so great in some cases).

> - You have functions with more than 5 formal parameters <snip>

I know of several _implementation_ classes that have nasty signatures but these are not part of the public, documented, library API. I've put a lot of effort into the design of core class API's and into hiding implementation detail from client programmers (e.g. use of the visitor pattern to hide details of working with ONMjs.Address instances). I think you were reviewing one of the undocumented implementation classes. There are definitely no public methods that take 5 parameters! IIRC the most complex public API is the signature of an app-defined observer callback function that takes three parameters.

You conclude with the following statement that I do not agree with at all:

> What we see here is the result of the common fallacy of overgeneralization, 
> the attempt at a one-size-fits-all solution that is supposed to make things 
> easier (but in the end doesn't).  The record shows that it is often better 
> to write code specific to a small purpose, and then combine specific code 
> for a larger purpose – transferring the “one tool for one purpose” approach 
> to general programming if you will.

I may or may not be able to sway your personal opinion on this point but I assure you that I considered this general wisdom carefully when breaking my use cases apart and coming up with core class structure and API's.

There are explicit decisions reflected in the overall design that were taken so as not to overreach. For example: the library supports serialization/deserialization to JSON but does not provide any persistence mechanism. The library supports the creation of resource identifier strings from ONMjs.Address but allows developers to choose the scope of uniqueness of these identifiers and does not implement a router. The library makes it simple to write re-usable and generic routines for handling display and user feedback via the DOM but doesn't touch the DOM itself.

There's a fair amount of subtlety involved in building a library designed to help people structure their application code via a design pattern - particularly one that's non-trivial. It's a delicate balance between providing too much, and too little.

The majority of my effort to-date has been invested in trying to achieve this balance and encapsulate it in a small collection of classes with a good API. It's a matter of opinion, and to some extent personal taste, if the design pattern suggested aligns with your way of thinking, or your problem. But all-things-to-all it is definitely not.

Again, thanks for taking the time to code review and comment Thomas. 

Regards, Chris






> 
> 
> 
> [Added attribution line; please do not remove next time]
> 
> 
> 
> > Thomas 'PointedEars' Lahn wrote:
> 
> >> http://pointedears.de/scripts/test/es-matrix/
> 
> > 
> 
> > Interesting matrix you've created. I'll need to parse further in order to
> 
> > identify just specifically which column my work falls in.
> 
> 
> 
> All of them, I presume.
> 
> 
> 
> CoffeeScript generates ECMAScript-based code (and each column of the feature 
> 
> table deals with one ECMAScript implementation, all of which should be 
> 
> capable in their current version to parse the code), but not necessarily 
> 
> good one.
> 
> 
> 
> In fact, the code you have generated suggests what I had suspected for a 
> 
> long time: that the code generated by it is very bad.  See below.
> 
>  
> 
> >>> The core ONMjs classes are dependency-free JavaScript
> 
> >> There are no classes in production-quality JavaScript yet
> 
> > 
> 
> > I made no such assertion.
> 
> 
> 
> Yes you did.  I have restored the quote above.
> 
> 
> 
> By “production-quality JavaScript” I mean a *JavaScript[tm]* script *engine* 
> 
> that is ready for use in production.  There has been an implementation of 
> 
> ECMAScript Edition 4, which introduced classes, JavaScript 2.0 
> 
> (“Epimetheus”), before it was abandoned, but it never was ready for use in 
> 
> production.  All other ECMAScript implementations are not (called (only)) 
> 
> JavaScript.  There is Microsoft JScript .NET for ASP .NET on IIS that does 
> 
> have classes, and there is ActionScript 2+ for Macromedia/Adobe Flash that 
> 
> does.
> 
> 
> 
> > Be kind to a C++ programmer who is making an effort to improve their
> 
> > knowledge and broaden their horizons. I know it's not perfect and can be
> 
> > improved. Specific criticisms would be helpful.
> 
> 
> 
> JavaScript[tm] is but one of many implementations of ECMAScript.  Client-
> 
> side ECMAScript implementations, with the exception of ActionScript 2+, are 
> 
> object-oriented languages that use *prototype*-based, not class-based, 
> 
> inheritance: Objects inherit properties from other objects, through a 
> 
> mechanism called “prototype chain”.
> 
> 
> 
> Nevertheless, objects created using a constructor, or a constructor whose 
> 
> prototype object (the object that its “prototype” property refers to) is in 
> 
> the prototype chain of the prototype object of another constructor, are 
> 
> called “instances” of that constructor in the Specification (hence the 
> 
> “instanceof” operator borrowed from Java).  Constructors are (WLOG) 
> 
> functions, and functions are first-class objects, (WLOG) Function instances.
> 
>  
> 
> >> you are using jQuery
> 
> > 
> 
> > ... as a convenience in JSFIDDLE examples, yes. Not as a dependency of the
> 
> > core classes that do not leverage JQuery (or any other library).
> 
> 
> 
> OK.  I found the following in your repository description confusing:
> 
> 
> 
> | Observer dependencies: JQuery, D3js, Knockout.js
> 
>  
> 
> >> Contrary to your statement, using the observer pattern, which I would
> 
> >> consider core functionality as described above <snip>
> 
> > 
> 
> > I don't follow. The ONMjs.Store class provides register/unregisterObserver
> 
> > methods and a documented API for the callbacks. Would you explain your
> 
> > point further please.
> 
>  
> 
> You have snipped my answer so that the quote does not contain my point.
> 
> But assuming that your previous statement is true, it is moot now.
> 
> 
> 
> >> I could not find any *relevant* *ECMAScript-based* code written by *you*
> 
> >> that would be on-topic here.
> 
> > 
> 
> > http://onmjs.encapsule.org/stage/js/core/
> 
> 
> 
> Thanks.
> 
>  
> 
> > Notwithstanding your objection to authoring in CoffeeScript, the contents
> 
> > of that directory is original. I'm not saying it's perfect, but it works
> 
>                                                                   ^^^^^^^^
> 
> > pretty well.
> 
>   ^^^^^^^^^^^^
> 
> Sigh. [psf 10.1]
> 
> 
> 
> > Enough so that I would write and ask you folks for some feedback.
> 
> 
> 
> It is worse than I initially expected.  Let us just look at the generated
> 
> ONMjs-core-model.js (which already is 21K uncompressed):
> 
> 
> 
> - You do *a lot* of pointless operations (that also add to the footprint). 
> 
>   While
> 
> 
> 
>   | var ONMjs, namespaceEncapsule;
> 
>   | 
> 
>   | namespaceEncapsule = (typeof Encapsule !== "undefined" && Encapsule
> 
>   |   !== null) && Encapsule || (this.Encapsule = {});
> 
> 
> 
>   is somewhat forgivable –
> 
> 
> 
>     var namespaceEncapsule =
> 
>       (typeof Encapsule !== "undefined" && Encapsule !== null)
> 
>         ? Encapsule
> 
>         : (this.Encapsule = {});
> 
> 
> 
>   would have been clearer, although “this.Encapsule = {}” is unnecessary
> 
>   if you return the reference to the object –
> 
> 
> 
>   | Encapsule.code.lib = (Encapsule.code.lib != null) && Encapsule.code.lib
> 
>   |   || (this.Encapsule.code.lib = {});
> 
> 
> 
>   is not.
> 
> 
> 
>     if (!Encapsule.code.lib)
> 
>     {
> 
>       Encapsule.code.lib = (this.Encapsule.code.lib = {});
> 
>     }
> 
> 
> 
>   is equivalent, more efficient, clearer code.  (But the double assignment
> 
>   is still bogus.)
> 
> 
> 
> - You have functions with more than 5 formal parameters:
> 
> 
> 
>   | buildOMDescriptorFromLayout = function(ONMD_, path_, parentDescriptor_,
> 
>   | componentDescriptor_, parentPathIdVector_,
> 
>   | parentPathExtensionPointIdVector_) {
> 
>   |   …
> 
>   | }
> 
> 
> 
>   No function should have more than 5 formal parameters because few people
> 
>   will remember them.  Use one Object-typed parameter if you cannot refactor
> 
>   top-down.
> 
> 
> 
> - You do type-converting comparisons against “null” for no obvious reason:
> 
> 
> 
>   | if (!((ONMD_ != null) && ONMD_)) {
> 
> 
> 
>     if (!ONMD_)
> 
>     {
> 
>       …
> 
>     }
> 
> 
> 
>   is equivalent, more efficient, and clearer.  There are no “null pointer
> 
>   accesses” that would need to be avoided in these languages: “null” is the
> 
>   sole value of the Null type, and type conversion (here: to Boolean) is
> 
>   implicit (unless prevented by strict comparison):
> 
> 
> 
>   | >>> var a = [[], [1], false, true, new Date(), function () {}, Math, -1,
> 
>   | 0, 1, NaN, -Infinity, Infinity, null, {}, {x: 42}, /(?:)/, /x/, "", "x",
> 
>   | void 0];
> 
>   | for (var i = a.length; i--;)
> 
>   | {
> 
>   |   var e = a[i];
> 
>   |   console.log(!((e != null && e)), !e);
> 
>   | }
> 
>   | 
> 
>   |     true true
> 
>   |     false false
> 
>   |     true true
> 
>   | (4) false false
> 
>   |     true true
> 
>   | (2) false false
> 
>   |     true true
> 
>   |     false false
> 
>   |     true true
> 
>   | (5) false false
> 
>   |     true true
> 
>   | (2) false false
> 
>   | ← undefined
> 
> 
> 
>   The only thing you do need to avoid to access *standalone identifiers*
> 
>   directly that may not have been declared (which is why the “typeof”
> 
>   operation has been used above).
> 
> 
> 
> - You throw unformatted strings for exceptions:
> 
> 
> 
>   | throw "Missing object model layout object input parameter! If you
> 
>   | specified the namespace declaration via object reference, check the
> 
>   | validity of the reference.";
> 
> 
> 
>   In order to determine *which* exception was thrown, the caller would have
> 
>   to do something error-prone like
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e.message == "Missing object model layout object input …")
> 
>       {
> 
>         // …
> 
>       }
> 
>     }
> 
> 
> 
>   when, if you had written, for example,
> 
> 
> 
>     throw new ONMjs.InvalidArgumentError("…");
> 
> 
> 
>   they could have written
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e && e.constructor == ONMjs.InvalidArgumentError)
> 
>       {
> 
>         // console.log(e.message);
> 
>       }
> 
>       else
> 
>       {
> 
>         throw e;
> 
>       }
> 
>     }
> 
> 
> 
>   or
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e instanceof ONMjs.InvalidArgumentError)
> 
>       {
> 
>         // console.log(e.message);
> 
>       }
> 
>       else
> 
>       {
> 
>         throw e;
> 
>       }
> 
>     }
> 
> 
> 
>   or in JavaScript 1.5+ even
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e if e instanceof ONMjs.InvalidArgumentError)
> 
>     {
> 
>       // console.log(e.message);      
> 
>     }
> 
> 
> 
> - All your methods are instance methods even when they could have been
> 
>   inherited from a prototype object which would have saved precious heap
> 
>   per instance:
> 
> 
> 
>   | this.getNamespaceDescriptorFromPath = function(path_) {
> 
>   |   try {
> 
>   |     return 
> 
>   |     
> 
> _this.getNamespaceDescriptorFromPathId(_this.getPathIdFromPath(path_));
> 
>   |   } catch (exception) {
> 
>   |     throw 
> 
> "ONMjs.implementation.ModelDetails.getNamespaceDescriptorFromPath failure: " 
> 
> + exception;
> 
>   |   }
> 
>   | };
> 
> 
> 
>   “_this” is merely your alias for “this” in the same execution context –
> 
> 
> 
> | var buildOMDescriptorFromLayout,
> 
> |   _this = this;
> 
> | 
> 
> 
> 
>   – so what's the point?
> 
> 
> 
> - None of this code is inline-commented and lines are far too long.
> 
>   It *is* hard to debug.
> 
> 
> 
> And so on.
> 
> 
> 
> I do not care if this nonsense was generated by CoffeeScript or if it was so 
> 
> in your original design.  All I do care about is that the outcome is bad 
> 
> code.
> 
> 
> 
> What we see here is the result of the common fallacy of overgeneralization, 
> 
> the attempt at a one-size-fits-all solution that is supposed to make things 
> 
> easier (but in the end doesn't).  The record shows that it is often better 
> 
> to write code specific to a small purpose, and then combine specific code 
> 
> for a larger purpose – transferring the “one tool for one purpose” approach 
> 
> to general programming if you will.
> 
> 
> 
> See also: 
> 
> <http://en.wikipedia.org/wiki/Framework_(computer_science)#Rationale>
> 
> 
> 
> > [Top post]
> 
> 
> 
> Please don't.
> 
> 
> 
> <http://PointedEars.de/faq>
> 
> 
> 
> -- 
> 
> PointedEars
> 
> 
> 
> Twitter: @PointedEars2
> 
> Please do not Cc: me. / Bitte keine Kopien per E-Mail.



On Tuesday, November 12, 2013 3:45:54 AM UTC-8, Thomas 'PointedEars' Lahn wrote:
> chrisrussell41@gmail.com wrote:
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> This is Usenet.  Your real name should go there.
> 
> 
> 
> [Added attribution line; please do not remove next time]
> 
> 
> 
> > Thomas 'PointedEars' Lahn wrote:
> 
> >> http://pointedears.de/scripts/test/es-matrix/
> 
> > 
> 
> > Interesting matrix you've created. I'll need to parse further in order to
> 
> > identify just specifically which column my work falls in.
> 
> 
> 
> All of them, I presume.
> 
> 
> 
> CoffeeScript generates ECMAScript-based code (and each column of the feature 
> 
> table deals with one ECMAScript implementation, all of which should be 
> 
> capable in their current version to parse the code), but not necessarily 
> 
> good one.
> 
> 
> 
> In fact, the code you have generated suggests what I had suspected for a 
> 
> long time: that the code generated by it is very bad.  See below.
> 
>  
> 
> >>> The core ONMjs classes are dependency-free JavaScript
> 
> >> There are no classes in production-quality JavaScript yet
> 
> > 
> 
> > I made no such assertion.
> 
> 
> 
> Yes you did.  I have restored the quote above.
> 
> 
> 
> By “production-quality JavaScript” I mean a *JavaScript[tm]* script *engine* 
> 
> that is ready for use in production.  There has been an implementation of 
> 
> ECMAScript Edition 4, which introduced classes, JavaScript 2.0 
> 
> (“Epimetheus”), before it was abandoned, but it never was ready for use in 
> 
> production.  All other ECMAScript implementations are not (called (only)) 
> 
> JavaScript.  There is Microsoft JScript .NET for ASP .NET on IIS that does 
> 
> have classes, and there is ActionScript 2+ for Macromedia/Adobe Flash that 
> 
> does.
> 
> 
> 
> > Be kind to a C++ programmer who is making an effort to improve their
> 
> > knowledge and broaden their horizons. I know it's not perfect and can be
> 
> > improved. Specific criticisms would be helpful.
> 
> 
> 
> JavaScript[tm] is but one of many implementations of ECMAScript.  Client-
> 
> side ECMAScript implementations, with the exception of ActionScript 2+, are 
> 
> object-oriented languages that use *prototype*-based, not class-based, 
> 
> inheritance: Objects inherit properties from other objects, through a 
> 
> mechanism called “prototype chain”.
> 
> 
> 
> Nevertheless, objects created using a constructor, or a constructor whose 
> 
> prototype object (the object that its “prototype” property refers to) is in 
> 
> the prototype chain of the prototype object of another constructor, are 
> 
> called “instances” of that constructor in the Specification (hence the 
> 
> “instanceof” operator borrowed from Java).  Constructors are (WLOG) 
> 
> functions, and functions are first-class objects, (WLOG) Function instances.
> 
>  
> 
> >> you are using jQuery
> 
> > 
> 
> > ... as a convenience in JSFIDDLE examples, yes. Not as a dependency of the
> 
> > core classes that do not leverage JQuery (or any other library).
> 
> 
> 
> OK.  I found the following in your repository description confusing:
> 
> 
> 
> | Observer dependencies: JQuery, D3js, Knockout.js
> 
>  
> 
> >> Contrary to your statement, using the observer pattern, which I would
> 
> >> consider core functionality as described above <snip>
> 
> > 
> 
> > I don't follow. The ONMjs.Store class provides register/unregisterObserver
> 
> > methods and a documented API for the callbacks. Would you explain your
> 
> > point further please.
> 
>  
> 
> You have snipped my answer so that the quote does not contain my point.
> 
> But assuming that your previous statement is true, it is moot now.
> 
> 
> 
> >> I could not find any *relevant* *ECMAScript-based* code written by *you*
> 
> >> that would be on-topic here.
> 
> > 
> 
> > http://onmjs.encapsule.org/stage/js/core/
> 
> 
> 
> Thanks.
> 
>  
> 
> > Notwithstanding your objection to authoring in CoffeeScript, the contents
> 
> > of that directory is original. I'm not saying it's perfect, but it works
> 
>                                                                   ^^^^^^^^
> 
> > pretty well.
> 
>   ^^^^^^^^^^^^
> 
> Sigh. [psf 10.1]
> 
> 
> 
> > Enough so that I would write and ask you folks for some feedback.
> 
> 
> 
> It is worse than I initially expected.  Let us just look at the generated
> 
> ONMjs-core-model.js (which already is 21K uncompressed):
> 
> 
> 
> - You do *a lot* of pointless operations (that also add to the footprint). 
> 
>   While
> 
> 
> 
>   | var ONMjs, namespaceEncapsule;
> 
>   | 
> 
>   | namespaceEncapsule = (typeof Encapsule !== "undefined" && Encapsule
> 
>   |   !== null) && Encapsule || (this.Encapsule = {});
> 
> 
> 
>   is somewhat forgivable –
> 
> 
> 
>     var namespaceEncapsule =
> 
>       (typeof Encapsule !== "undefined" && Encapsule !== null)
> 
>         ? Encapsule
> 
>         : (this.Encapsule = {});
> 
> 
> 
>   would have been clearer, although “this.Encapsule = {}” is unnecessary
> 
>   if you return the reference to the object –
> 
> 
> 
>   | Encapsule.code.lib = (Encapsule.code.lib != null) && Encapsule.code.lib
> 
>   |   || (this.Encapsule.code.lib = {});
> 
> 
> 
>   is not.
> 
> 
> 
>     if (!Encapsule.code.lib)
> 
>     {
> 
>       Encapsule.code.lib = (this.Encapsule.code.lib = {});
> 
>     }
> 
> 
> 
>   is equivalent, more efficient, clearer code.  (But the double assignment
> 
>   is still bogus.)
> 
> 
> 
> - You have functions with more than 5 formal parameters:
> 
> 
> 
>   | buildOMDescriptorFromLayout = function(ONMD_, path_, parentDescriptor_,
> 
>   | componentDescriptor_, parentPathIdVector_,
> 
>   | parentPathExtensionPointIdVector_) {
> 
>   |   …
> 
>   | }
> 
> 
> 
>   No function should have more than 5 formal parameters because few people
> 
>   will remember them.  Use one Object-typed parameter if you cannot refactor
> 
>   top-down.
> 
> 
> 
> - You do type-converting comparisons against “null” for no obvious reason:
> 
> 
> 
>   | if (!((ONMD_ != null) && ONMD_)) {
> 
> 
> 
>     if (!ONMD_)
> 
>     {
> 
>       …
> 
>     }
> 
> 
> 
>   is equivalent, more efficient, and clearer.  There are no “null pointer
> 
>   accesses” that would need to be avoided in these languages: “null” is the
> 
>   sole value of the Null type, and type conversion (here: to Boolean) is
> 
>   implicit (unless prevented by strict comparison):
> 
> 
> 
>   | >>> var a = [[], [1], false, true, new Date(), function () {}, Math, -1,
> 
>   | 0, 1, NaN, -Infinity, Infinity, null, {}, {x: 42}, /(?:)/, /x/, "", "x",
> 
>   | void 0];
> 
>   | for (var i = a.length; i--;)
> 
>   | {
> 
>   |   var e = a[i];
> 
>   |   console.log(!((e != null && e)), !e);
> 
>   | }
> 
>   | 
> 
>   |     true true
> 
>   |     false false
> 
>   |     true true
> 
>   | (4) false false
> 
>   |     true true
> 
>   | (2) false false
> 
>   |     true true
> 
>   |     false false
> 
>   |     true true
> 
>   | (5) false false
> 
>   |     true true
> 
>   | (2) false false
> 
>   | ← undefined
> 
> 
> 
>   The only thing you do need to avoid to access *standalone identifiers*
> 
>   directly that may not have been declared (which is why the “typeof”
> 
>   operation has been used above).
> 
> 
> 
> - You throw unformatted strings for exceptions:
> 
> 
> 
>   | throw "Missing object model layout object input parameter! If you
> 
>   | specified the namespace declaration via object reference, check the
> 
>   | validity of the reference.";
> 
> 
> 
>   In order to determine *which* exception was thrown, the caller would have
> 
>   to do something error-prone like
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e.message == "Missing object model layout object input …")
> 
>       {
> 
>         // …
> 
>       }
> 
>     }
> 
> 
> 
>   when, if you had written, for example,
> 
> 
> 
>     throw new ONMjs.InvalidArgumentError("…");
> 
> 
> 
>   they could have written
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e && e.constructor == ONMjs.InvalidArgumentError)
> 
>       {
> 
>         // console.log(e.message);
> 
>       }
> 
>       else
> 
>       {
> 
>         throw e;
> 
>       }
> 
>     }
> 
> 
> 
>   or
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e)
> 
>     {
> 
>       if (e instanceof ONMjs.InvalidArgumentError)
> 
>       {
> 
>         // console.log(e.message);
> 
>       }
> 
>       else
> 
>       {
> 
>         throw e;
> 
>       }
> 
>     }
> 
> 
> 
>   or in JavaScript 1.5+ even
> 
> 
> 
>     try
> 
>     {
> 
>       yourFunction();
> 
>     }
> 
>     catch (e if e instanceof ONMjs.InvalidArgumentError)
> 
>     {
> 
>       // console.log(e.message);      
> 
>     }
> 
> 
> 
> - All your methods are instance methods even when they could have been
> 
>   inherited from a prototype object which would have saved precious heap
> 
>   per instance:
> 
> 
> 
>   | this.getNamespaceDescriptorFromPath = function(path_) {
> 
>   |   try {
> 
>   |     return 
> 
>   |     
> 
> _this.getNamespaceDescriptorFromPathId(_this.getPathIdFromPath(path_));
> 
>   |   } catch (exception) {
> 
>   |     throw 
> 
> "ONMjs.implementation.ModelDetails.getNamespaceDescriptorFromPath failure: " 
> 
> + exception;
> 
>   |   }
> 
>   | };
> 
> 
> 
>   “_this” is merely your alias for “this” in the same execution context –
> 
> 
> 
> | var buildOMDescriptorFromLayout,
> 
> |   _this = this;
> 
> | 
> 
> 
> 
>   – so what's the point?
> 
> 
> 
> - None of this code is inline-commented and lines are far too long.
> 
>   It *is* hard to debug.
> 
> 
> 
> And so on.
> 
> 
> 
> I do not care if this nonsense was generated by CoffeeScript or if it was so 
> 
> in your original design.  All I do care about is that the outcome is bad 
> 
> code.
> 
> 
> 
> What we see here is the result of the common fallacy of overgeneralization, 
> 
> the attempt at a one-size-fits-all solution that is supposed to make things 
> 
> easier (but in the end doesn't).  The record shows that it is often better 
> 
> to write code specific to a small purpose, and then combine specific code 
> 
> for a larger purpose – transferring the “one tool for one purpose” approach 
> 
> to general programming if you will.
> 
> 
> 
> See also: 
> 
> <http://en.wikipedia.org/wiki/Framework_(computer_science)#Rationale>
> 
> 
> 
> > [Top post]
> 
> 
> 
> Please don't.
> 
> 
> 
> <http://PointedEars.de/faq>
> 
> 
> 
> -- 
> 
> PointedEars
> 
> 
> 
> Twitter: @PointedEars2
> 
> Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22013

*Please* leave the attribution, and with regard to your other postings, 
please include a trimmed quotation.  Even Google Groups' attribution novel 
and a full quote (*please* do not do that *again*) is better than no 
attribution and no quotation at all.

See also <http://PointedEars.de/faq/notes/posting> pp.


Chris Russell wrote:

[Restored attribution line]

> [Thomas 'PointedEars' Lahn wrote:]
>> - You have functions with more than 5 formal parameters <snip>
> 
> I know of several _implementation_ classes that have nasty signatures but
> these are not part of the public, documented, library API. I've put a lot
> of effort into the design of core class API's and into hiding
> implementation detail from client programmers (e.g. use of the visitor
> pattern to hide details of working with ONMjs.Address instances). I think
> you were reviewing one of the undocumented implementation classes. There
> are definitely no public methods that take 5 parameters! IIRC the most
> complex public API is the signature of an app-defined observer callback
> function that takes three parameters.

You have requested a code review: You have presented your source code to 
your fellow software developers to get their opinion on it.  It does not 
matter in that regard, then, which parts of your code are exposed to the 
uninitiated public.  The recommendation that no function/method should have 
more than 5 formal parameters (preferably less) applies to *all* (good) 
code, following from the fact that your fellow software developers, who 
would like to understand your code and might want to fork it, are people, 
too.

(Not only) I would appreciate it if you did not trim quotations in the 
middle of a sentence, before the point made with that sentence or paragraph 
is visible.  If you want to save space, trim the pointless attribution 
novels and full quotes instead.
 
> You conclude with the following statement that I do not agree with at all:
> 
>> What we see here is the result of the common fallacy of
>> overgeneralization, the attempt at a one-size-fits-all solution that is
>> supposed to make things easier (but in the end doesn't).  The record
>> shows that it is often better to write code specific to a small purpose,
>> and then combine specific code for a larger purpose – transferring the
>> “one tool for one purpose” approach to general programming if you will.
> 
> I may or may not be able to sway your personal opinion on this point but I
> assure you that I considered this general wisdom carefully when breaking
> my use cases apart and coming up with core class structure and API's.
> 
> There are explicit decisions reflected in the overall design that were
> taken so as not to overreach. For example: the library supports
> serialization/deserialization to JSON but does not provide any persistence
> mechanism. The library supports the creation of resource identifier
> strings from ONMjs.Address but allows developers to choose the scope of
> uniqueness of these identifiers and does not implement a router. The
> library makes it simple to write re-usable and generic routines for
> handling display and user feedback via the DOM but doesn't touch the DOM
> itself.
> 
> There's a fair amount of subtlety involved in building a library designed
> to help people structure their application code via a design pattern -
> particularly one that's non-trivial. It's a delicate balance between
> providing too much, and too little.
> 
> The majority of my effort to-date has been invested in trying to achieve
> this balance and encapsulate it in a small collection of classes with a
> good API. It's a matter of opinion, and to some extent personal taste, if
> the design pattern suggested aligns with your way of thinking, or your
> problem. But all-things-to-all it is definitely not.

(I did not know how to trim this so I left it as it is.)

Perhaps it would be easier to see the additional value of your work *here* 
if you gave a short example of its use *here*.
 
> Again, thanks for taking the time to code review and comment Thomas.

You're welcome.
 
-- 
PointedEars

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

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

#21986

On Mon, 11 Nov 2013 22:15:18 -0800 (PST), chrisrussell41@gmail.com
wrote:

  <snip>
  [Thomas wrote :]
>> There are no classes in production-quality JavaScript yet
>
>I made no such assertion. Be kind to a C++ programmer
  <snip>

As a C++ programmer you probably know that many C++ compilers make use
of "V-tables", one per class. What many people don't know is that a
V-table does much the same job as an ECMAScript object's prototype
chain. In particular, methods (aka "member functions") common to
objects of the same kind are referenced by the prototype chain, just
as they are referenced by a class's V-table.

If you know some C++ history you'll know that the early C++ compilers
compiled into C source code, which was then compiled by a handy C
compiler into an executable program. But C has no classes! Shock!
Horror! How can this be?

What Thomas doesn't understand is that you can play the same trick in
an ECMAScript program : the programmer decides what the objects
belonging to a class should be like, then does most of the work of
writing the code that makes it happen. A C++ compiler writes most of
that code for you, and makes sure you can't shoot yourself in the foot
by messing up the objects.

So, to summarise, there is only one major difference between classes
in C++ and carefully defined collections of objects in ECMAScript :
that is that you can tell a C++ compiler what an object looks like,
but in ECMAScript the compiler wouldn't understand it. (At least, not
until the 'class' keyword comes into common use). It is entirely
legitimate to say that some objects belong to the same class, if that
is your design intent.

  John

PS I predict that Thomas will reject this as Heresy, with all the
penalties that heresy usually receives.

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

#21988

John Harris wrote:

> On Mon, 11 Nov 2013 22:15:18 -0800 (PST), chrisrussell41@gmail.com
> wrote:
> 
>   <snip>
>   [Thomas wrote :]
>>> There are no classes in production-quality JavaScript yet
>>
>> I made no such assertion. Be kind to a C++ programmer
>   <snip>
> 
> As a C++ programmer you probably know that many C++ compilers make use
> of "V-tables", one per class. What many people don't know is that a
> V-table does much the same job as an ECMAScript object's prototype
> chain. In particular, methods (aka "member functions") common to
> objects of the same kind are referenced by the prototype chain, just
> as they are referenced by a class's V-table.
> 
> If you know some C++ history you'll know that the early C++ compilers
> compiled into C source code, which was then compiled by a handy C
> compiler into an executable program. But C has no classes! Shock!
> Horror! How can this be?
> 
> What Thomas doesn't understand is that you can play the same trick in
> an ECMAScript program : the programmer decides what the objects
> belonging to a class should be like, then does most of the work of
> writing the code that makes it happen. A C++ compiler writes most of
> that code for you, and makes sure you can't shoot yourself in the foot
> by messing up the objects.
> 
> So, to summarise, there is only one major difference between classes
> in C++ and carefully defined collections of objects in ECMAScript :
> that is that you can tell a C++ compiler what an object looks like,
> but in ECMAScript the compiler wouldn't understand it. (At least, not
> until the 'class' keyword comes into common use). It is entirely
> legitimate to say that some objects belong to the same class, if that
> is your design intent.

Well, would you have presented C code which was generated by an early
C++ "compiler" in a newsgroup about C?  Wouldn't a newsgroup about C++
have been the appropriate address?

-- 
Christoph M. Becker

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

#21989

Christoph Michael Becker wrote:

> John Harris wrote:
>> [the usual ad hominem and misconceptions]
> 
> Well, would you have presented C code which was generated by an early
> C++ "compiler" in a newsgroup about C?  Wouldn't a newsgroup about C++
> have been the appropriate address?

*Please* do not feed the troll.

-- 
PointedEars

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

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

#21996

On Wed, 13 Nov 2013 00:17:59 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Christoph Michael Becker wrote:
>
>> John Harris wrote:
>>> [the usual ad hominem and misconceptions]
>> 
>> Well, would you have presented C code which was generated by an early
>> C++ "compiler" in a newsgroup about C?  Wouldn't a newsgroup about C++
>> have been the appropriate address?
>
>*Please* do not feed the troll.

It is Thomas's very humble opinion that what I wrote is not the most
useful description of an ECMAScript program, and differing from
Thomas's opinion is the action of a raving lunatic.

Also in Thomas's very humble opinion this is a discussion group but
the only discussion permitted is I agree with Thomas, I agree with
Thomas, I agree with Thomas.

  John

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

#21997

On Tue, 12 Nov 2013 23:33:23 +0100, Christoph Michael Becker
<cmbecker69@arcor.de> wrote:

>John Harris wrote:

  <snip>
>> So, to summarise, there is only one major difference between classes
>> in C++ and carefully defined collections of objects in ECMAScript :
>> that is that you can tell a C++ compiler what an object looks like,
>> but in ECMAScript the compiler wouldn't understand it. (At least, not
>> until the 'class' keyword comes into common use). It is entirely
>> legitimate to say that some objects belong to the same class, if that
>> is your design intent.
>
>Well, would you have presented C code which was generated by an early
>C++ "compiler" in a newsgroup about C?  Wouldn't a newsgroup about C++
>have been the appropriate address?

In the time before there was a C++ group someone could well have
written that they have implemented classes in C, only to have some
berk shouting THERE ARE NO CLASSES IN C. Think about it.

  John

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

#21998

Hey! Knock it off you guys <wink />

I'm trying to share a design pattern that I believe is useful, get some feedback, and learn how to write better ECMAScript (nod to Thomas) via CoffeeScript, or by hand, or by whatever means gets me a readable, testable, and performant result with the minimum of pain and effort. It would please me if you guys would help me get there :)

-C

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

#21999

I filed issues against myself based on Thomas' feedback yesterday to correct error handling (now throwing of raw strings), clean-up wasteful existential tests, and refactor as many instance functions to prototype functions as possible in my core library code. I don't think I captured all the subtle points Thomas made, but these three seem to be the most important.

I'll circle back in a couple days when I've got fixes. 

How many of you currently are leveraging MVC, or MVVM frameworks? If you don't mind sharing some details about how you're applying and what your challenges are that would be super interesting.

-C

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

#22007

Chris Russell wrote:

> I filed issues against myself […]

*g*

> How many of you currently are leveraging MVC, or MVVM frameworks?

I am using MVC with Magento, which itself is based on Zend Framework (ZF, 
for PHP).  The ECMAScript Support Matrix, Version 2, uses another MVC 
framework for PHP (PHPX) that I created for this purpose, based on ideas 
from ZF; it has found other applications since.

I have been using MVVM with Silverlight/WPF shortly last year, and was 
already intrigued by it; in particular, I found the data binding approach in 
XAML fascinating.  It can probably be done for HTML in ECMAScript now that 
we have standard-native setters and getters, and hopefully soon, proxy 
objects.

> If you don't mind sharing some details about how you're applying
> and what your challenges are that would be super interesting.

It might be a discussion for another newsgroup, though.

-- 
PointedEars

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

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

#22028

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> chrisrussell41@gmail.com wrote:

>> (compiled from CoffeeScript sources),
>
> “generated bloat code

OK.

> that cannot be debugged”

To be fair, that "cannot" is an environment variable of sorts. You
*could* debug CoffeScript in Google Chrome, or in IntelliJ IDEA as
a Node.js application in local mode. As long as the next version of the
Browser, the IDE, the source map generation of the transpiler or any
combination of those doesn't break it. People who are used to GNU/Linux
should be able to enjoy that :-)

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

#22071

On Saturday, November 16, 2013 5:21:32 PM UTC-8, Eric Bednarz wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> > chrisrussell41@gmail.com wrote:
> >> (compiled from CoffeeScript sources),
Thomas > > “generated bloat code
Eric > OK.
Thomas > > that cannot be debugged”

Eric > To be fair, that "cannot" is an environment variable of sorts. You
> *could* debug CoffeScript in Google Chrome, or in IntelliJ IDEA as
> a Node.js application in local mode. As long as the next version of the
> Browser, the IDE, the source map generation of the transpiler or any
> combination of those doesn't break it. People who are used to GNU/Linux
> should be able to enjoy that :-)

Eric, the actual library is distributed as ECMAScript transcoded from sources written in CoffeeScript. Although it's possible to include the CoffeeScript sources and depend on CoffeeScript to do the transcoding at run-time (definitely difficult to debug) that's not what I'm doing here.

Thomas - I've been busy but am working on some fixes and will definitely post up some simple examples here as you suggest.

Thanks, Chris

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

#22078

Chris Russell <chrisrussell41@gmail.com> writes:

> On Saturday, November 16, 2013 5:21:32 PM UTC-8, Eric Bednarz wrote:

>> You *could* debug CoffeScript in Google Chrome, or in IntelliJ IDEA as
>> a Node.js application in local mode. As long as the next version of the
>> Browser, the IDE, the source map generation of the transpiler or any
>> combination of those doesn't break it. People who are used to GNU/Linux
>> should be able to enjoy that :-)
>
> Eric, the actual library is distributed as ECMAScript transcoded from
> sources written in CoffeeScript.

I think we all understood that. And that's potentially difficult to
debug.

> Although it's possible to include the
> CoffeeScript sources and depend on CoffeeScript to do the transcoding
> at run-time (definitely difficult to debug) that's not what I'm doing
> here.

I wouldn't know about run-time transcoding, I was talking about source
maps. Easy to debug with. As long as it works (the Lord giveth, the Lord
taketh away).

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

#22175

A well designed library should encapsulate its functionality sufficiently so that developers can concentrate on debugging their own code and not waste time spelunking through the library implementation. FWIW, that's what I'm shooting for. As mentioned previously, I still owe Thomas some examples but am busy moving everything into Yeoman. Also hitting the CoffeeScript groups for additional guidance to address the list of deficiencies noted earlier on this thread. Hoping to have this available as an npm package sometime early 2014. Thanks, Chris

On Tuesday, November 19, 2013 4:41:16 PM UTC-8, Eric Bednarz wrote:
> Chris Russell <chrisrussell41@gmail.com> writes:
> 
> 
> 
> > On Saturday, November 16, 2013 5:21:32 PM UTC-8, Eric Bednarz wrote:
> 
> 
> 
> >> You *could* debug CoffeScript in Google Chrome, or in IntelliJ IDEA as
> 
> >> a Node.js application in local mode. As long as the next version of the
> 
> >> Browser, the IDE, the source map generation of the transpiler or any
> 
> >> combination of those doesn't break it. People who are used to GNU/Linux
> 
> >> should be able to enjoy that :-)
> 
> >
> 
> > Eric, the actual library is distributed as ECMAScript transcoded from
> 
> > sources written in CoffeeScript.
> 
> 
> 
> I think we all understood that. And that's potentially difficult to
> 
> debug.
> 
> 
> 
> > Although it's possible to include the
> 
> > CoffeeScript sources and depend on CoffeeScript to do the transcoding
> 
> > at run-time (definitely difficult to debug) that's not what I'm doing
> 
> > here.
> 
> 
> 
> I wouldn't know about run-time transcoding, I was talking about source
> 
> maps. Easy to debug with. As long as it works (the Lord giveth, the Lord
> 
> taketh away).

[toc] | [prev] | [standalone]

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

csiph-web