getFunctionName v1.0

[Ian Osgood]

Being a regular reader of this group you may notice and participate
this thread:

<http://groups-beta.google.com/group...+insubject:2005&rnum=1&hl=en#0165a598d06dc3da>

I need to repeat that IE5.0 for Mac remains a *forced exception* for
the list above *if you want to go really global*. Mac itself did not
manage to do anything good as browser, and that IE5.0 still rather
popular on Apple platforms. It has beem made nearly as personal present
from Bill Gates to Steve Jobs (why - goes too far offtopic) using
provided open source codes of Mac OS. This is why it has exellent
rendering abilities. Unfortunately Firefox for Mac has some serious
productivity ussies (lesser on Linux). And who wants to see his/her
$2000 beauty acting like PC AT ?

And I looked through the Safary [sic]. My guess was right: it's the same very
good "NN4 for Mac" engine patched here and there with *very selected*
pieces of modern technologies. Someone just took the license-freed code
from AOL and did hash-hash with it for OS X release. If you're starving
of hostalgia, you even can use again <layer..> <nolayers>... blocks.
(Who understands and remembers - put the tears off your eyes

Uh... Safari has nothing to do with NN4. It is based on KHTML and KJS
from the KDE Konqueror browser. It seems as fast and standards
compliant as any of the other popular browsers.

Good luck to you if you want to alienate all the Mac users out there
(yeah, yeah, only 3% market share). Safari has a "Report a Bug" button
in its toolbar. If enough people click it for your web sites, Steve
Jobs will send his goons to have a private "chat" with you.

 

[VK]

Good luck to you if you want to alienate all the Mac users out there

(yeah, yeah, only 3% market share).

As I said: "I need to repeat that IE5.0 for Mac remains a *forced
exception* for
the list above *if you want to go really global*."

And Safary is simply out of reach for debugging for Windows platform. I
had to look around for a while to find a friend of friend of mine just
to see Safary in action. But I cannot take it home neither I'm buying a
"debugging Macintosh" :-(

Just FYI: Steven King uses Macintosh only. It doesn't say what browser,
but it is said that he never shanges anything as it came out of the
box. So I guess he's using Safary now

 

[Ian Osgood]

And Safary [sic] is simply out of reach for debugging for Windows platform. I
had to look around for a while to find a friend of friend of mine just
to see Safary [sic] in action. But I cannot take it home neither I'm buying a
"debugging Macintosh" :-(

But the Mac Mini is so cute. Its target market is cross platform
development. Apple sez:

Perfect for Programmers

Set a space-saving Mac mini atop your PC workstation
and add a KVM switch to share keyboard, monitor and
mouse. Mac OS X includes free developer tools for Mac,
UNIX and Java. Relegate that PC to the testbed.

 

[Richard Cornford]

How much you bet?

"Demonstrating the futility" seems a good summation of this thread.

IE5.5 and higher / FF 1.0.3 and higher / Opera 8.0 and
higher (no IE4, NN2 etc. - sorry)

Not even close to cross-browser then.

Overall real comment should be done on the code like this:

var obj1 = new Object();
var obj2 = obj1;

<COMMENT>
Never ever make multiple references on the same object,
however it would seem necessary by the program logic!
(check your logic instead). Multiple references is the
most effective way to bring your memory into the trashhold
state.
</COMMENT>

Another near incoherent expression of ill-informed and inaccurate bad
advice. Making this nonsense up off the top of your head and writing it
down doesn't make it true. More reasonable advice would be that if you
find yourself concerned by a need to discover the defined name of a
function you are doing something wrong (and would be better checking
your logic at that point).

So how much you bet?

Anything you like. You would be better of learning javascript before
pontificating about it.

Richard.

 

[Lasse Reichstein Nielsen]

<COMMENT>
Never ever make multiple references on the same object, however it
would seem necessary by the program logic! (check your logic instead).
Multiple references is the most effective way to bring your memory into
the trashhold state.
</COMMENT>

Where did you pick up that idea? Only having one reference to each
object would make most object oriented programming impossible. Even
passing an object reference as a parameter to a method would be
impossible.

OO language are build to allow multiple references to objects, so that
alone is not a problem for memory (whatever a "trashhold state" is).

/L

 

[VK]

Where did you pick up that idea? Only having one reference to each
object would make most object oriented programming impossible. Even
passing an object reference as a parameter to a method would be
impossible.

OO language are build to allow multiple references to objects, so that
alone is not a problem for memory (whatever a "trashhold state" is).

Please do not substitute the subject. Passing object reference to
functions and constructors is the base of OP, it would be stupid to
talk against it. But in such case you have a call chain that:
1) allows engine/you to dismiss objects automatically or manually
2) allows you to backtrace the original literal name (side effect).

By explicetly doing somethin like:

var ref1 = new someObject();
ref2 = ref1;

or even:

var ref1 = new someObject();
ref2 = ref1;
ref1 = newValue;

you're getting 90% guarantee that this instance will be never
dismissed: neither by you (because the literal is not available) nor by
engine (because you twisted its brains off). Good if it's some Object()
based crap: it may go away eventually after unload. Bad is it's an
automation object: you'll end up with running copies of it until the OS
restart.

 

[Baconbutty]

I am not sure actually. I probably have not reflected on it.

I'll do a simple search and replace, and do as you suggest.

 

[Richard Cornford]

Please do not substitute the subject.

Subjects are at best the starting point for a thread. Threads then go
off wherever they will.

By explicetly doing somethin like:

var ref1 = new someObject();
ref2 = ref1;

or even:

var ref1 = new someObject();
ref2 = ref1;
ref1 = newValue;

you're getting 90% guarantee that this instance will be never
dismissed: neither by you (because the literal is not
available) nor by engine (because you twisted its brains off).

Rubbish. Assuming that 'dismissed' is a reference to garbage collection
then there is no issue here. Javascript garbage collection has no
problems handling multiple references to the same object.

Good if it's some Object() based crap: it may go
away eventually after unload. Bad is it's an automation
object: you'll end up with running copies of it
until the OS restart.

Learning javascript and browser scripting would be more productive than
making up voodoo stories about it and then putting them across as if you
know something about the subject.

Richard.

 

[Christopher J. Hahn]

VK wrote:
[snip]

you're getting 90% guarantee that this instance will be never
dismissed: neither by you (because the literal is not available) nor by
engine (because you twisted its brains off). Good if it's some Object()
based crap: it may go away eventually after unload. Bad is it's an
automation object: you'll end up with running copies of it until the OS
restart.

You're a PERL guy, right? Garbage collection in JS works just like
PERL's.

Whenever a variable's internal reference count reaches 0, it is
considered disposable and is disposed of.

The following lines do the exact same thing in JS as they do in PERL
(copy/paste them if you want):
$x = { };
$y = $x;
$x = { };
$y = { };

They differ only in that in JS { } is an object literal, and in PERL {
} is a hash literal, but that's immaterial to this discussion.

The thing created on line 1 is not garbage collected until line 4, and
it will ALWAYS be garbage collected at line 4. You can depend upon it.
There is no mystery to when an object is disposed of.

It is disposed of when the number of references to it reaches zero.
Plain and simple. No 'eventually' about it.

Period.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Wed, 27 Jul 2005 13:05:05, seen in VK

Lines: 39

As well as

.... irrelevant waffle.

Oh com'on... Read the linked topic.

The fact remains that you made a false statement, either by intention or
by carelessness. Your code did not work everywhere, not even in all
javascript browsers in current use.

 

[VK]

You're a PERL guy, right? Garbage collection in JS works just like

PERL's.

I had to work a lot with Perl during The Bubble, but it was a "forced
marriage" (good contract = CGI = Perl).
Personally I think it was a language the least suited for Web. Just one
of the Bubble's twists: it was available, it was semi-working, it was
free and opps... it's a world wide standard.

The memory issues never bothered me there as I knew Perl only from its
CGI-script side. And on each shared server there was a "serial object
killer" launched by admin. After the assigned deadline it would simply
kill your context no matter was it in use or trach leftovers. So the
task was to do it as quick as possible and get out

Whenever a variable's internal reference count reaches 0, it is
considered disposable and is disposed of.

The following lines do the exact same thing in JS as they do in PERL
(copy/paste them if you want):
$x = { };
$y = $x;
$x = { };
$y = { };

They differ only in that in JS { } is an object literal, and in PERL {
} is a hash literal, but that's immaterial to this discussion.

The thing created on line 1 is not garbage collected until line 4, and
it will ALWAYS be garbage collected at line 4. You can depend upon it.
There is no mystery to when an object is disposed of.

It is disposed of when the number of references to it reaches zero.
Plain and simple. No 'eventually' about it.

Period.

That's a great piece of info if you really sure about it!

Still I cannot understand why would anyone need two co-existing
references to the same object in the same namespace. For sport? To
check the garbage collector? JavaScript fully supports object
construction, extention and inheritance. If you really want to stay
within OP that would be plenty enough.

 

[VK]

You're a PERL guy, right? Garbage collection in JS works just like

PERL's.

I had to work a lot with Perl during The Bubble, but it was a "forced
marriage" (good contract = CGI = Perl).
Personally I think it was a language the least suited for Web. Just one
of the Bubble's twists: it was available, it was semi-working, it was
free and opps... it's a world wide standard.

The memory issues never bothered me there as I knew Perl only from its
CGI-script side. And on each shared server there was a "serial object
killer" launched by admin. After the assigned deadline it would simply
kill your context no matter was it in use or trach leftovers. So the
task was to do it as quick as possible and get out

Whenever a variable's internal reference count reaches 0, it is
considered disposable and is disposed of.

The following lines do the exact same thing in JS as they do in PERL
(copy/paste them if you want):
$x = { };
$y = $x;
$x = { };
$y = { };

They differ only in that in JS { } is an object literal, and in PERL {
} is a hash literal, but that's immaterial to this discussion.

The thing created on line 1 is not garbage collected until line 4, and
it will ALWAYS be garbage collected at line 4. You can depend upon it.
There is no mystery to when an object is disposed of.

It is disposed of when the number of references to it reaches zero.
Plain and simple. No 'eventually' about it.

Period.

That's a great piece of info if you really sure about it!

Still I cannot understand why would anyone need two co-existing
references to the same object in the same namespace. For sport? To
check the garbage collector? JavaScript fully supports object
construction, extention and inheritance. If you really want to stay
within OP that would be plenty enough.

 

[Jason Dufair]

engine (because you twisted its brains off). Good if it's some Object()

You know, it was only through a great deal of restraint that I prevented
myself from spraying my keyboard with soda after the "trashhold" thing,
then you have to go and write about twisting a GC's brains off! Now
look at the mess I have!

--
Jason Dufair - (e-mail address removed)
http://www.dufair.org/
Crazy just thinkin' knowing that the world is round
And here I'm dancing on the ground
Never right side up or upside down
Is this real or am I dreaming?
-- Dave Matthews Band, "Crush"

 

[VK]

You know, it was only through a great deal of restraint that I prevented
myself from spraying my keyboard with soda after the "trashhold" thing,
then you have to go and write about twisting a GC's brains off! Now
look at the mess I have!

<FLUD>
It's just nothing. But if you see a thread here about *class* or *hash*
you better read it without a coffee in your hand or some unexpected and
painful physical damage is nearly guaranteed.
</FLUD>

 

[Christopher J. Hahn]

I had to work a lot with Perl during The Bubble, but it was a "forced
marriage" (good contract = CGI = Perl).
Personally I think it was a language the least suited for Web. Just one
of the Bubble's twists: it was available, it was semi-working, it was
free and opps... it's a world wide standard.

No oops about it... if you need fast code, do C. If you need code fast,
do PERL.

The memory issues never bothered me there as I knew Perl only from its
CGI-script side.

In which memory issues can and often are far more prevalent.

And on each shared server there was a "serial object
killer" launched by admin. After the assigned deadline it would simply
kill your context no matter was it in use or trach leftovers. So the
task was to do it as quick as possible and get out

Isn't it always?

That's a great piece of info if you really sure about it!

Technically it becomes "available for disposal". In practice the engine
might dispose of it in a few nano- or micro- seconds. By spec I believe
it is *allowed* to wait until it's damned good and ready, but the point
is that after the object's internal reference count reaches 0 it
becomes unreferrable and it *will* certainly be garbage-collected.

There are certainly ways to defeat this if you want to, but garbage
collection is fairly well-defined and dependable, and you can predict
what will be disposed of if you understand what you're coding.

*IF* you understand what you're doing.

Something we should all strive for, yes?

Still I cannot understand why would anyone need two co-existing
references to the same object in the same namespace. For sport? To
check the garbage collector? JavaScript fully supports object
construction, extention and inheritance. If you really want to stay
within OP that would be plenty enough.

For simplicity, efficiency, maintainability, readbility, and plain
elegance of code.

Consider this:

var c = 0,
things = [
new Thing(1),
new Thing(2),
// ...
new Thing(20)
];


/* the next statement creates a second reference to an existing object
* that already has a reference stored in the things[] array.
*/
while( thing = things[ ++c ] ) {
// figure out some x and y coords
thing.position( x, y );
thing.show();
}


Almost any time you need to perform multiple operations on an arbitrary
object independent of its name, it doesn't make sense but to store a
second reference to it.

Why wouldn't you?