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


Groups > comp.lang.javascript > #22013

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

Message-ID <2303657.KmGbDlK0D1@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2013-11-15 14:14 +0100
Subject Re: Introducing Object Namespace Manager library (ONMjs) and the MSOFS pattern
Newsgroups comp.lang.javascript
References <e2c157e9-d330-4422-8628-79cd9a0a52ad@googlegroups.com> <17113478.8IimEn4RK4@PointedEars.de> <b6d9cdf3-5071-4e8f-bff8-7c0695386326@googlegroups.com> <5021733.WrF0io4ur8@PointedEars.de> <fe69df7e-c44c-48f7-9391-6ad368dc6365@googlegroups.com>

Show all headers | View raw


*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.

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


Thread

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

csiph-web