Yes I am well aware of the concept and do enjoy cute answers from time
to time, but it still does not answer the question. But at any rate I
believe this is a better article in regards to namespacing:
On Jan 2, 1:18 am, jemptymethod wrote:
> On Jan 1, 8:48 pm, "Michael Haufe (TNO)"
> wrote:
>
I'm not sure you understood my question -
If all the private scope does is being run on construction, there's no
reason to give it an object. the whole point of using a closure is that you
can create "private" methods.
The way I understand public/private concept is that you create a distinction
bet
Sometimes I mention that I had an opportunity to use JSON on a project
in 2004, before the Ajax (and, in turn, JSON) "explosion" in 2005.
And some people quietly walk away, and then try to convince others I
couldn't possibly know what I'm talking about.
Can anybody prove JSON existed in 2004, or p
On Jan 1, 6:56 pm, RobG wrote:
>
> The use of $ may be Ok in ECMA-5, but it still grates with me. If you
> want to be able to safely access "private" variables and objects, you
> need privileged functions that are available externally.
Which my "module" code plainly provides
>
> > return (fu
On Jan 1, 8:48 pm, "Michael Haufe (TNO)"
wrote:
> Unless private variables contain some type of uber-secret personally
> damning info, why not just use this?
Consider familiarizing yourself with the module pattern, see
http://www.yuiblog.com/blog/2007/06/12/module-pattern/ publish a
couple of mon
On Jan 1, 6:36 pm, Peter van der Zee wrote:
> On Sun, Jan 2, 2011 at 12:17 AM, jemptymethod wrote:
>
> > On Jan 1, 10:08 am, jmulligan wrote:
> > > I do something similar with my lib (http://github.com/avoidwork/
> > > abaaso) that's under dev. It works well, but you can't use private and
> > > p
On a related note - I'm disappointed ES5 did not simply make the
arguments object an array. No host object excuse there either.
Any inside info on why they did not? I can't see much of a backward
compatability issue other than making a bunch of [].slice.call syntax
redundant.
Angus
On Jan 1, 10:
On 1/1/11, Angus Croll wrote:
> Hi Joe,
>
> Array is a constructor which is a function, and Function has no slice
> function.
No, but in some implementations such as Mozillas', the Array
constructor has generic methods including `slice`.
var arr = Array.slice(arrayLike);
The value in that is
Whoops I accidentally copied the word prototype into the last 3
examples
Should read:
new Array().slice.call(array,0);
Array().slice.call(array,0);
[].slice.call(array,0);
sorry about that
Angus
On Jan 1, 7:23 pm, Angus Croll wrote:
> Hi Joe,
>
> Array is a constructor which is a function, and
Hi Joe,
Array is a constructor which is a function, and Function has no slice
function.
Slice is actually defined on Array.prototype so you could say:
Array.prototype.slice.call(array,0)
This would be the most transparent syntax.
However since every array instance inherits from Array.prototype,
Unless private variables contain some type of uber-secret personally
damning info, why not just use this?
//JS 1.8
function Point(x,y){
this._x = Math.floor(x);
this._y = Math.floor(y);
}
Point.prototype = {
constructor : Point,
get x() this._x,
set x(p) this._x = Math.floor(p)
On Jan 2, 9:19 am, jemptymethod wrote:
> On Jan 1, 12:48 am, jemptymethod wrote:
>
> > Please consider the following template. Sure its a little verbose,
> > but Uncle Bob declare comments to be failures, so I'm trying to
> > obviate such failure with the identifiers $private and $public. Als
> Instead of $ (dollar) prefix, you could also _ (underscore) prefix private
> methods. That way you don't have to artificially grow your (public) method
> names with php-like ugliness. I personally use the $ prefix for variables
> returned by libraries like jquery or prototype. To easily distinct
On Sun, Jan 2, 2011 at 12:17 AM, jemptymethod wrote:
> On Jan 1, 10:08 am, jmulligan wrote:
> > I do something similar with my lib (http://github.com/avoidwork/
> > abaaso) that's under dev. It works well, but you can't use private and
> > public. they're reserved.
>
> That's why I slap "$" on fr
On Jan 1, 12:48 am, jemptymethod wrote:
> Please consider the following template. Sure its a little verbose,
> but Uncle Bob declare comments to be failures, so I'm trying to
> obviate such failure with the identifiers $private and $public. Also
> the nested closures allow all state to be hidden
On Jan 1, 10:08 am, jmulligan wrote:
> I do something similar with my lib (http://github.com/avoidwork/
> abaaso) that's under dev. It works well, but you can't use private and
> public. they're reserved.
That's why I slap "$" on front of private and public.
--
To view archived discussions from
On Jan 1, 1:15 am, אריה גלזר wrote:
> Maybe it's because of the lack of real examples, but I failed to understand
> the need for so many closures:
> 1. Why do you create a list of private methods that even the inner module
> cannot access?
> 2. Why make the constructor private?
> 3. Why wrap the p
I'm going to vacation, so tomorrow I won't be online, will answer later
if something.
Happy New Year again for everyone ;)
Dmitry.
On 02.01.2011 1:27, Dmitry A. Soshnikov wrote:
On 02.01.2011 1:22, Garrett Smith wrote:
On 1/1/11, Dmitry A. Soshnikov wrote:
On 02.01.2011 0:27, Garrett Smith
On 02.01.2011 1:22, Garrett Smith wrote:
On 1/1/11, Dmitry A. Soshnikov wrote:
On 02.01.2011 0:27, Garrett Smith wrote:
On 1/1/11, Dmitry A. Soshnikov wrote:
On 01.01.2011 4:01, Garrett Smith wrote:
The correct answer is that it's function declaration! And from this
step, there are two reas
On 1/1/11, Dmitry A. Soshnikov wrote:
> On 02.01.2011 0:27, Garrett Smith wrote:
>> On 1/1/11, Dmitry A. Soshnikov wrote:
>>> On 01.01.2011 4:01, Garrett Smith wrote:
>>> The correct answer is that it's function declaration! And from this
>>> step, there are two reasons of the issue.
>>>
>> No, t
Notice though, that I started the thread that explanation were
_incomplete_. I don't say they are completely were wrong. Again, they
were just incorrect in respect of the SyntaxError _reasons_. Of course
if the explanation is started from: /"we need to have a function
expression here, and there
On 12/31/10, Joe wrote:
>> Caching a property lookup is usually not really worth it*. Best
>> consideration for doing it anyways is clean code. But don't do it for
>> speed.
>
> In terms of data access, object property lookup *is* slower than using
> a local variable. Peter's right that for the mo
On 02.01.2011 0:27, Garrett Smith wrote:
On 1/1/11, Dmitry A. Soshnikov wrote:
On 01.01.2011 4:01, Garrett Smith wrote:
On 12/31/10, fernando trasvina wrote:
why this is not treated the same way as:
function(x){}(1);
That is a SyntaxError. The most recent message on this thread (mine),
On 1/1/11, Dmitry A. Soshnikov wrote:
> On 01.01.2011 4:01, Garrett Smith wrote:
>> On 12/31/10, fernando trasvina wrote:
>>
>>
>>> why this is not treated the same way as:
>>>
>>> function(x){}(1);
>>>
>> That is a SyntaxError. The most recent message on this thread (mine),
>> explains that the
Thanks Marc! :D From: Marc Harter
Sent: Saturday, January 01, 2011 1:30 PM
To: jsmentors@googlegroups.com
Subject: [JSMentors] Kudos
This group has just blown up and become a rich community for learning
JavaScript from one another. Kudos. Glad to be here. Thanks mentors
for really stepping up, w
This group has just blown up and become a rich community for learning
JavaScript from one another. Kudos. Glad to be here. Thanks mentors
for really stepping up, without that I don't think it would have
become as rich as it has thus far.
Happy New Year!
Marc (@wavded)
--
To view archived disc
Happy new year ;)
> Remember, a A FunctionDeclaration's function is added to the
> VariableEnvironment in Variable Instantiation. It is not and cannot be an
> ExpressionStatement.
>
> An FunctionExpression is an ExpressionStatement; it is not bound to the VE
> (VariableEnvironment) on entering an
2010/12/31 Salohcin :
> I'm not sure there is any measurable benefit so to speak. Someone with
> more knowledge on the subject can correct me if i'm wrong.
In my particular case, some weeks ago I was able to speed-up a
function by about 30% using variable caching (i.e. "var cachedProp =
obj.proper
2010/12/31 Joe :
> I'm running through John Resig's "Learning Advanced JavaScript" and I
> ran into some questions when I got to slide #45 (http://ejohn.org/apps/
> learn/#45).
> In the example, an arguments collection is passed to a function which
> is supposed to return a true array of the conten
On Dec 31 2010, 9:31 pm, jemptymethod wrote:
> > Please do not top post.
> > --
> > Garrett
>
> Please don't encourage others to focus on this sort of thing,
> otherwise this group promises to devolve into the same useless mess
> that c.l.js is. The content is what's important, and you managed t
> As a bonus question, why did he use parentheses, saying
> "Array().slice..." instead of just "Array.slice"?
>
> - Joe
This is the actual problem. "Array" is a constructor function.
"Array()" gives you an actual array object. "slice" is not something
you can do to functions, only arrays.
_jas
I'm running through John Resig's "Learning Advanced JavaScript" and I
ran into some questions when I got to slide #45 (http://ejohn.org/apps/
learn/#45).
In the example, an arguments collection is passed to a function which
is supposed to return a true array of the contents of arguments. I
figured
> Caching a property lookup is usually not really worth it*. Best
> consideration for doing it anyways is clean code. But don't do it for speed.
In terms of data access, object property lookup *is* slower than using
a local variable. Peter's right that for the most part it doesn't
matter and that
I do something similar with my lib (http://github.com/avoidwork/
abaaso) that's under dev. It works well, but you can't use private and
public. they're reserved.
As per the 'why do you do that?' static methods in a class structure.
On Jan 1, 12:48 am, jemptymethod wrote:
> Please consider the fo
I'm not sure there is any measurable benefit so to speak. Someone with
more knowledge on the subject can correct me if i'm wrong.
For me, it's a stylistic/readability issue. I always use a local
variable for the base object. A small example:
var someObject = {
property: "value"
};
someObject
On 01.01.2011 13:42, Dmitry A. Soshnikov wrote:
On 01.01.2011 4:01, Garrett Smith wrote:
On 12/31/10, fernando trasvina wrote:
why this is not treated the same way as:
function(x){}(1);
That is a SyntaxError. The most recent message on this thread (mine),
explains that the production for
On 01.01.2011 0:55, Marc Harter wrote:
The thing is that (almost?) all explanations (I repeat -- books, articles, etc)
talked about `calling`, that is wrong. While the reason is that parentheses at
the end are not parentheses of a call (`Arguments` production), but just a
grouping operator (wi
On 01.01.2011 2:08, Garrett Smith wrote:
On 12/31/10, Marc Harter wrote:
The thing is that (almost?) all explanations (I repeat -- books, articles,
etc) talked about `calling`, that is wrong. While the reason is that
parentheses at the end are not parentheses of a call (`Arguments`
production),
On 01.01.2011 2:43, fernando trasvina wrote:
Hi. very nice explanation but what i don't fully understand is why the grouping
operator makes the parenthesis following the function declaration work as call.
(function(x){alert(x)}(1));
why this is not treated the same way as:
function(x){}(1);
On 01.01.2011 4:01, Garrett Smith wrote:
On 12/31/10, fernando trasvina wrote:
why this is not treated the same way as:
function(x){}(1);
That is a SyntaxError. The most recent message on this thread (mine),
explains that the production for ExpressionStatement explicitly
forbids an Express
40 matches
Mail list logo
