Bug in "Move to/Namespace"? 
Author Message
 Bug in "Move to/Namespace"?

Hi!

I tried to move DoME (part of the goodies) to it's own namespace: open
parcel-browser, switch to "categories"-view, selected a DoME-categorie,
selected all classes in this categorie and choosen "Move To/Namespace" from
pop-up-menu. In most cases this worked well, but with the class
"AlterEnvViewer" this results the dump below:

I don't know, if this is a bug in dome or in vwnc?

dpi
---cut---
'Unhandled exception: Message not understood: #sender'
NameSpace(Object)>>doesNotUnderstand:
AlterEnvViewer>>environment:
AlterEnvViewer class>>environment:
NameSpace>>relocateObject:from:
AlterEnvViewer class(Class)>>relocateTo:
optimized [] in ClassesBrowserHelper>>moveNameSpace
OrderedCollection>>do:
NameSpaceCategoryBrowserHelper(ClassesBrowserHelper)>>moveNameSpace
SimpleBrowserModule>>dispatch:
SimpleBrowserModule>>doesNotUnderstand:
EmulatedSequenceController(SequenceController)>>dispatchMenuSymbol:
EmulatedSequenceController(SequenceController)>>dispatchMenuSelection:
EmulatedSequenceController(ControllerWithMenu)>>processMenuAt:centered:
EmulatedSequenceController(ControllerWithMenu)>>yellowButtonPressedEvent:
EmulatedSequenceController(SequenceController)>>yellowButtonPressedEvent:
YellowButtonPressedEvent>>dispatchTo:
---cut---



Tue, 14 Oct 2003 23:22:57 GMT  
 Bug in "Move to/Namespace"?


10:22 AM:
[...]

Quote:
> I tried to move DoME (part of the goodies) to it's own namespace: open
> parcel-browser, switch to "categories"-view, selected a DoME-categorie,
> selected all classes in this categorie and choosen "Move To/Namespace" from
> pop-up-menu. In most cases this worked well, but with the class
> "AlterEnvViewer" this results the dump below:

> I don't know, if this is a bug in dome or in vwnc?

> dpi
> ---cut---
> 'Unhandled exception: Message not understood: #sender'
> NameSpace(Object)>>doesNotUnderstand:
> AlterEnvViewer>>environment:
> AlterEnvViewer class>>environment:
> NameSpace>>relocateObject:from:

The browser is invoking #environment: on AlterEnvViewer.  Unfortunately,
this is a method defined in a superclass, Class (inspect AlterEnvViewer and
double-click on superclass repeatedly to see its ancestry).  Class needs
#environment: to have specific semantics relating to namespaces if it's to
work correctly.

Specific Solution:  Rename the #environment: method to be something else
(and fix the appropriate senders).

General Solution:  Get rid of the probably useless class side #environment:
method and stop using the disgusting Singleton pattern, *especially* the
practice of replicating setters to the class side.

General Solution for Cincom:  Method namespaces.

Theoretical Solution drawn from C++:  Use private inheritance between Object
class and Class.  Not possible (ever) in Smalltalk due to absence of static
type information.

If you're worried that this type of problem might happen again (as you
should), you may want to

    (1) look for other occurrences of the same problem (overriding
#environment: in a class method)
    (2) look for occurrences of essential similar problems (overriding other
Class methods in class methods, for example #name and #name:)
    (3) look for occurrences of the general class of problems (e.g.,
accidentally using the 'name' classInstanceVariable in a class method)
    (4) solve the language problem that lead to the initial error.
    (5) share that solution with your language/tool vendor and the general
public.

Quote:
> AlterEnvViewer class(Class)>>relocateTo:
> optimized [] in ClassesBrowserHelper>>moveNameSpace
> OrderedCollection>>do:
> NameSpaceCategoryBrowserHelper(ClassesBrowserHelper)>>moveNameSpace
> SimpleBrowserModule>>dispatch:
> SimpleBrowserModule>>doesNotUnderstand:
> EmulatedSequenceController(SequenceController)>>dispatchMenuSymbol:
> EmulatedSequenceController(SequenceController)>>dispatchMenuSelection:
> EmulatedSequenceController(ControllerWithMenu)>>processMenuAt:centered:
> EmulatedSequenceController(ControllerWithMenu)>>yellowButtonPressedEvent:
> EmulatedSequenceController(SequenceController)>>yellowButtonPressedEvent:
> YellowButtonPressedEvent>>dispatchTo:
> ---cut---



Thu, 16 Oct 2003 05:15:39 GMT  
 Bug in "Move to/Namespace"?


Wed, 18 Jun 1902 08:00:00 GMT  
 Bug in "Move to/Namespace"?


Quote:
>General Solution:  Get rid of the probably useless class side #environment:
>method and stop using the disgusting Singleton pattern, *especially* the
>practice of replicating setters to the class side.

Mark, are you talking about singletons in general, or a specific
instance of a singleton pattern?

Kevin Szabo
--
Kevin Szabo ---- "I am Fudd of Borg. Wesistance is usewess!"



Fri, 17 Oct 2003 17:40:57 GMT  
 Bug in "Move to/Namespace"?


Quote:


>> General Solution:  Get rid of the probably useless class side #environment:
>> method and stop using the disgusting Singleton pattern, *especially* the
>> practice of replicating setters to the class side.

> Mark, are you talking about singletons in general, or a specific
> instance of a singleton pattern?

Both, but I'll just cover the general case and leave the rest up to your
imagination.

I have not yet seen a single "valid" use of the singleton pattern.  There
might be one out there somewhere, but every time I've seen one it has caused
the system to be limited in serious, fundamental ways.

To quote the GoF,

<Quote>
SINGLETON

Intent
    Ensure a class only has one instance, and provide a global point of
access to it.

Motivation
    It's important for some classes to have exactly one instance.  Although
there can be many printers in a system, there should be only one printer
spooler.  There should be only one file system and one window manager.  A
digital filter will have one A/D converter.  An accounting system will be
dedicated to serving one company.
</Quote>

Every one of those use cases is entirely, 180 degrees wrong.  There should
be many printer spoolers.  There should be many file systems.  There should
be many window managers.  A digital filter must work with multiple A/D
converters.  Accounting systems are virtually useless when applicable to a
single company.

Printer spoolers:  Why should there be only one process per "system" allowed
to interface to printers?  Possibly to avoid contention when transmitting
data to a physical printer.  But that would be served *better* by having one
spooler per printer.

File Systems:  VisualWorks is the only system I've seen that can deal with
multiple file systems (and multiple file naming rules) simultaneously.  If
you have the right drivers you can access a file on a DOS-format disk
mounted on a Linux box networked to your Mac.  The only thing that allows
this is the *absence* of singletons in the relevant areas.

Window Manager:  Give me a break.  I use two monitors on my Mac (on and
off).  Having two window managers wouldn't be that big a deal.  In fact,
under Mac OS X I can have both Mac OS X and Mac OS 9 windows on the same
screen.  Probably implemented by writing a delegating singleton, but it
would be no problem normall.  Under X-Windows you should be able to have
multiple "servers" connect to a "client" (pardon the silly reversed
terminology).  The window manager "clients" should not have to run in
separate processes, one per connected window manager "server".

Digital Filter:  So you'd never want to use your filter in a mixer?  It
would be *IMPOSSIBLE* if you used a singleton.  You couldn't filter two
inputs because *THE SINGLETON'S SOLE PURPOSE IS TO PREVENT IT FROM WORKING
WITH TWO*.

Take the accounting system.  This ridiculous assumption alone must have cost
companies *billions* of dollars during mergers.  The accounting systems that
encode the organization for which they are executing in *CODE* deserve to be
as brittle as they typically are.  Programmers see their company name in the
code (or a previous name of the company!), and immediately start writing
their own code in such a way that it could *never* be applied in any other
context.  Even TopMind wouldn't advocate having a variable named
"number_of_BigMacs" in McDonald's accounting systems.

Some more examples:

The Windows Registry is one huge COMMON section, a table containing a
million global variables.  You might think "but at least they're
name-spaced", but that's only in the sense that a COBOL data area has
name-spaces.

The Mac Desktop file (or its current incarnation) is not much better (well,
at least you can rebuild it from the applications without having to run
thousands of installers).  Ah, but on the Mac each volume has its own
Desktop file.

Multiprocessors break some programs' assumption that there is only one
processor.  Fortunately, this particular assumption will induce "bit rot" in
programs that make it, as multiprocessor systems gradually become more
common, then ubiquitous.

Even in hardware, singleton fallacies are gradually disappearing.  I don't
remember the manufacturer (probably SGI), but on some systems they don't
even have a single data bus (let alone a single processor).  A "Crossbar
Bus", if I recall, allowing the components to communicate in K concurrent
two-party data transfers.

The only singleton that makes sense to me is the current Process (not
thread).  But again, that assumes a memory architecture in which only one
Process's address space is visible.  This is not true of systems, say,
running the 603e PowerPC processor (if memory serves).  That system had page
protection but no virtual-to-physical address translation.  Thus, every
process had the same "address space" but the processes could only see
mutually disjoint pieces of it.  Note that some forms of interrupts, or any
code that runs in Supervisor (Kernel, Ring 0, whatever) mode have exactly
ZERO instances of Process "active".  Thus, code in an interrupt handler
cannot access a Process "singleton".  If you build an OS Kernel that tries
to make the assumption that processes can access this singleton, any
libraries that actually *do* make use of it will be unusable within
interrupt handlers.  The use of this particular form of "singleton" may be
responsible for (1) the difficulty of writing (good) interrupt handlers, and
(2) the instability of many handlers that are out there already.  No wonder
so many OSes have resorted to running handlers in their own (User-level)
processes (although there are other very good technological reasons for
this).

Did I miss any?

Quote:
> Kevin Szabo

P.S., Carleton, mid '80s?  Or am I confusing you with someone else?  It's
been a while.


Sat, 18 Oct 2003 15:10:17 GMT  
 Bug in "Move to/Namespace"?


Wed, 18 Jun 1902 08:00:00 GMT  
 Bug in "Move to/Namespace"?

Quote:



[...]

> > Mark, are you talking about singletons in general, or a specific
> > instance of a singleton pattern?

> Both, but I'll just cover the general case and leave the rest up to your
> imagination.

> I have not yet seen a single "valid" use of the singleton pattern.  There
> might be one out there somewhere, but every time I've seen one it has caused
> the system to be limited in serious, fundamental ways.

[...]

There are valid uses of singleton, in VisualWorks nil, true and false
are the obvious examples.

I agree that a lot of frameworks rely too much on a 'default' instance
of stuff like a print spooler being available.
However, I disagree that is an instance of the singleton pattern because
in those cases it is permissable to create additional instances if you
need to. A restrictive implementation of singleton would override #new
to prevent additional instances being created.

Reinout
-------

  reinout.vcf
< 1K Download


Sat, 18 Oct 2003 17:25:55 GMT  
 Bug in "Move to/Namespace"?
Mark,

Quote:
> > I have not yet seen a single "valid" use of the singleton pattern.
There
> > might be one out there somewhere, but every time I've seen one it has
caused
> > the system to be limited in serious, fundamental ways.

> [...]

> There are valid uses of singleton, in VisualWorks nil, true and false
> are the obvious examples.

> I agree that a lot of frameworks rely too much on a 'default' instance
> of stuff like a print spooler being available.
> However, I disagree that is an instance of the singleton pattern because
> in those cases it is permissable to create additional instances if you
> need to. A restrictive implementation of singleton would override #new
> to prevent additional instances being created.

I think there are "valid" uses of Singleton (as Reinout mentions) but also
there are "useful" applications of the pattern that are perhaps not quite as
fundamental and therefore perhaps not "valid" in you sense of the word. One
of the things that Singleton does is to *simplify* access to commonly used
objects. This fits in with the XP notion of "do the simplest thing that
could possibly work". If you are pretty sure (99%) at the time of writing
that you'll only ever need to access one file system then it's fine to make
this a singleton. When you discover that multiple file systems are necessary
then you'll refactor to be able to pass the active system around through
each message send. To make the code over-flexible up front is usually a
mistake since it involves a complexity expense that is unlikely ever to be
needed (1% in this case).

Actually, in Dolphin ST we have adopted our own modification of Singleton
(unfortunately we haven't given it a unique name). The idea is that of
default instances. Sometimes, for eg, you might have a default instance of
an object that is commonly accessed but you don't want to disallow the
creation of occasional additional instances. Here we have a class method,
default (sorry the hash sign has broken on my keyboard), that provides acce
ss to the default instance but we don't override new to prevent the
creation of new instances. One example of the use of this is in source code
control: SourceRepository has a default instance that gives access to the
current repository. Most everyday operations involve this. However,
sometimes it may be necessary to open another repository (perhaps to backup
source from the current one) so this isn't explicitly disallowed.

This idea is used a fair few times in the Dolphin image. Another one that
comes to mind is ExternalLibrary sub-instances. The subclasses of
ExternalLibrary represent DLLs and normally you only ever need one default
instance of a DLL object to be able to call the functions within it.
However, there's nothing to stop you creating further instances if you wish.

Best Regards,

Andy Bower
Object Arts Ltd.
http://www.*-*-*.com/

"Not all {*filter*}ions are bad for you"
http://www.*-*-*.com/ {*filter*}ion.htm



Sat, 18 Oct 2003 18:23:05 GMT  
 Bug in "Move to/Namespace"?
I agree with most of this.  But I believe that there 2 contributing factors to
its miss use.

    1) It was in the holy grail pattern book.  So people use it because it must
be good.
    2) It is really not an object-oriented pattern.  What I mean here is that
one of the great benefits to Objects is the ability to multiply.  We can create
as many as we need of whatever.  This is a tremendous advantage and one we often
take for granted and forget about.  However Singletons basically take this away.

Almost every Singleton ever created has comeback to bite its users.

Chris Lopeman

Quote:

> Mark,

> > > I have not yet seen a single "valid" use of the singleton pattern.
> There
> > > might be one out there somewhere, but every time I've seen one it has
> caused
> > > the system to be limited in serious, fundamental ways.

> > [...]

> > There are valid uses of singleton, in VisualWorks nil, true and false
> > are the obvious examples.

> > I agree that a lot of frameworks rely too much on a 'default' instance
> > of stuff like a print spooler being available.
> > However, I disagree that is an instance of the singleton pattern because
> > in those cases it is permissable to create additional instances if you
> > need to. A restrictive implementation of singleton would override #new
> > to prevent additional instances being created.

> I think there are "valid" uses of Singleton (as Reinout mentions) but also
> there are "useful" applications of the pattern that are perhaps not quite as
> fundamental and therefore perhaps not "valid" in you sense of the word. One
> of the things that Singleton does is to *simplify* access to commonly used
> objects. This fits in with the XP notion of "do the simplest thing that
> could possibly work". If you are pretty sure (99%) at the time of writing
> that you'll only ever need to access one file system then it's fine to make
> this a singleton. When you discover that multiple file systems are necessary
> then you'll refactor to be able to pass the active system around through
> each message send. To make the code over-flexible up front is usually a
> mistake since it involves a complexity expense that is unlikely ever to be
> needed (1% in this case).

> Actually, in Dolphin ST we have adopted our own modification of Singleton
> (unfortunately we haven't given it a unique name). The idea is that of
> default instances. Sometimes, for eg, you might have a default instance of
> an object that is commonly accessed but you don't want to disallow the
> creation of occasional additional instances. Here we have a class method,
> default (sorry the hash sign has broken on my keyboard), that provides acce
> ss to the default instance but we don't override new to prevent the
> creation of new instances. One example of the use of this is in source code
> control: SourceRepository has a default instance that gives access to the
> current repository. Most everyday operations involve this. However,
> sometimes it may be necessary to open another repository (perhaps to backup
> source from the current one) so this isn't explicitly disallowed.

> This idea is used a fair few times in the Dolphin image. Another one that
> comes to mind is ExternalLibrary sub-instances. The subclasses of
> ExternalLibrary represent DLLs and normally you only ever need one default
> instance of a DLL object to be able to call the functions within it.
> However, there's nothing to stop you creating further instances if you wish.

> Best Regards,

> Andy Bower
> Object Arts Ltd.
> http://www.*-*-*.com/

> "Not all {*filter*}ions are bad for you"
> http://www.*-*-*.com/ {*filter*}ion.htm



Sun, 19 Oct 2003 02:17:12 GMT  
 Bug in "Move to/Namespace"?

Quote:

> There are valid uses of singleton, in VisualWorks nil, true and false
> are the obvious examples.

Why should nil be a singleton?  I can come up with some examples where I
wish it wasn't, and I have to "work around" the system to compensate.

Actually, this is one I wouldn't mind David Simmons commenting on.

--

Nevin Pratt

http://www.smalltalk.org/consultants.html
(801) 455-1839, (801) 292-7804



Sun, 19 Oct 2003 04:34:16 GMT  
 Bug in "Move to/Namespace"?
I would think the basic reason behind nil being a singleton is that nothing
can ever be different from one nil to the next, so why not make it a
singleton.  In addition I would think that the average smalltalk memory
footprint would double or triple if it was not.
Quote:


> > There are valid uses of singleton, in VisualWorks nil, true and false
> > are the obvious examples.

> Why should nil be a singleton?  I can come up with some examples where I
> wish it wasn't, and I have to "work around" the system to compensate.

> Actually, this is one I wouldn't mind David Simmons commenting on.

> --

> Nevin Pratt

> http://www.smalltalk.org/consultants.html
> (801) 455-1839, (801) 292-7804



Sun, 19 Oct 2003 05:15:01 GMT  
 Bug in "Move to/Namespace"?
You're missing one of the most obvious singleton examples:

    A "class" is a singleton instance of its "metaclass".

In that situation, it is quite appropriate. This is a classic aggregation
scenario which divides object behavior into discrete
roles/interface/protocol.

One of the big issues in many Smalltalk implementations is misplaced
meta-object protocol operations and state/support data. In other words,
meta-object protocol should be in the metaclass, not its class.

The #environment: issue that began this thread, in part, stems from this
issue.

---

However, even that responsibility structuring does not solve the general
issue of selector-name collisions.

That's why, when I designed SmallScript in 1998, I fully extended the basic
namespace scoping system I had designed into QKS Smalltalk (namespace system
designed in 1991; scoping extended in 1994).

For our purposes here: A "scope" is a namespace (which is really a
class/metaclass via its classPool). A message selector is a <Symbol>, which
consists of both a canonical array of characters representing its
family-name, and a (<Behavior>) representing its scope/namespace within that
family. <Symbol> is a subclass of <String>. The AOS (Agents Object System)
Platform's object model intrinsically manages character storage for all
objects and provides WideChar and encoding as a basic object attribute for
character storage; hence we only require a a single class for <Symbol>.

Under this model, a selector-name to method implementation binding
incorporates the scope information into the binding process. Thus, in
SmallScript, every message you send has a selector-name whose scope forms
the calling-scope.  Every method implementation has at least one message
selector-name and may have more than one; those implementation
selector-names also include a scope that forms the binding-scope.

When the binder is looking for methods it chooses the best fit method based
on matching the calling message-selector to the available method
selector-names within the method dictionary inheritance lattice.

Thus, set of all methods that match on the selector-name family, are then
collated based on the scope distance between the calling message
selector-name's scope and the candidate method implementation's
selector-name scope. The method implementation with the shortest distance is
the best "scope" fit; there are also other fit criteria such as argument
type, etc.
============

If the preceding was unclear, then I'll try to illustrate it with sample
code:
----------------------------------------------------------------------------
-

"" Scoped to <IMetaprotocol>
method class: AlterEnvViewer scope: IMetaprotocol [
environment:
    ...
].

"" Globally scoped method -- scope <any>
method class: AlterEnvViewer [
environment:
    ...
].

"" Thus the following default and explicit binding can be used
eval [
    "" Binds based on the scopes visible to this 'eval' method
    AlterEnvViewer environment: ...

    "" Binds based on visibility from the <IMetaprotocol> scope
    AlterEnvViewer#IMetaprotocol.environment: ...
].

"" Or, we could use something like
class name: NSManager imports: IMetaprotocol [
    class-method [
    relocateObject: subject from: srcContext to: destContext
        ...

        "" Here we can be confident that the #environment
        "" message binding will use the <IMetaprotocol>
        "" version. We are safe from other variations or
        "" implementations that may exist in our object-space.
        ""
        "" Why? Because the #environment message is actually
        "" #NSManager.private.environment:. Which has an unrolled
        "" scope path of: {NSManager.private, NSManager, IMetaprotocol, ...}
        ""
        "" Which means that in searching for a best scope fit, for the
        "" the #environment: selector-family it will bind to an
        "" <IMetaprotocol> scoped method before scope's other than
        "" {NSManager.private, NSManager}.
        subject environment: ...
        ...
    ].
].

-- Dave S.



Quote:




> >> General Solution:  Get rid of the probably useless class side
#environment:
> >> method and stop using the disgusting Singleton pattern, *especially*
the
> >> practice of replicating setters to the class side.

> > Mark, are you talking about singletons in general, or a specific
> > instance of a singleton pattern?

> Both, but I'll just cover the general case and leave the rest up to your
> imagination.

> I have not yet seen a single "valid" use of the singleton pattern.  There
> might be one out there somewhere, but every time I've seen one it has
caused
> the system to be limited in serious, fundamental ways.

> To quote the GoF,

> <Quote>
> SINGLETON

> Intent
>     Ensure a class only has one instance, and provide a global point of
> access to it.

> Motivation
>     It's important for some classes to have exactly one instance.
Although
> there can be many printers in a system, there should be only one printer
> spooler.  There should be only one file system and one window manager.  A
> digital filter will have one A/D converter.  An accounting system will be
> dedicated to serving one company.
> </Quote>

> Every one of those use cases is entirely, 180 degrees wrong.  There should
> be many printer spoolers.  There should be many file systems.  There
should
> be many window managers.  A digital filter must work with multiple A/D
> converters.  Accounting systems are virtually useless when applicable to a
> single company.

> Printer spoolers:  Why should there be only one process per "system"
allowed
> to interface to printers?  Possibly to avoid contention when transmitting
> data to a physical printer.  But that would be served *better* by having
one
> spooler per printer.

> File Systems:  VisualWorks is the only system I've seen that can deal with
> multiple file systems (and multiple file naming rules) simultaneously.  If
> you have the right drivers you can access a file on a DOS-format disk
> mounted on a Linux box networked to your Mac.  The only thing that allows
> this is the *absence* of singletons in the relevant areas.

> Window Manager:  Give me a break.  I use two monitors on my Mac (on and
> off).  Having two window managers wouldn't be that big a deal.  In fact,
> under Mac OS X I can have both Mac OS X and Mac OS 9 windows on the same
> screen.  Probably implemented by writing a delegating singleton, but it
> would be no problem normall.  Under X-Windows you should be able to have
> multiple "servers" connect to a "client" (pardon the silly reversed
> terminology).  The window manager "clients" should not have to run in
> separate processes, one per connected window manager "server".

> Digital Filter:  So you'd never want to use your filter in a mixer?  It
> would be *IMPOSSIBLE* if you used a singleton.  You couldn't filter two
> inputs because *THE SINGLETON'S SOLE PURPOSE IS TO PREVENT IT FROM WORKING
> WITH TWO*.

> Take the accounting system.  This ridiculous assumption alone must have
cost
> companies *billions* of dollars during mergers.  The accounting systems
that
> encode the organization for which they are executing in *CODE* deserve to
be
> as brittle as they typically are.  Programmers see their company name in
the
> code (or a previous name of the company!), and immediately start writing
> their own code in such a way that it could *never* be applied in any other
> context.  Even TopMind wouldn't advocate having a variable named
> "number_of_BigMacs" in McDonald's accounting systems.

> Some more examples:

> The Windows Registry is one huge COMMON section, a table containing a
> million global variables.  You might think "but at least they're
> name-spaced", but that's only in the sense that a COBOL data area has
> name-spaces.

> The Mac Desktop file (or its current incarnation) is not much better
(well,
> at least you can rebuild it from the applications without having to run
> thousands of installers).  Ah, but on the Mac each volume has its own
> Desktop file.

> Multiprocessors break some programs' assumption that there is only one
> processor.  Fortunately, this particular assumption will induce "bit rot"
in
> programs that make it, as multiprocessor systems gradually become more
> common, then ubiquitous.

> Even in hardware, singleton fallacies are gradually disappearing.  I don't
> remember the manufacturer (probably SGI), but on some systems they don't
> even have a single data bus (let alone a single processor).  A "Crossbar
> Bus", if I recall, allowing the components to communicate in K concurrent
> two-party data transfers.

> The only singleton that makes sense to me is the current Process (not
> thread).  But again, that assumes a memory architecture in which only one
> Process's address space is visible.  This is not true of systems, say,
> running the 603e PowerPC processor (if memory serves).  That system had
page
> protection but no virtual-to-physical address translation.  Thus, every
> process had the same "address space" but the processes could only see
> mutually disjoint pieces of it.  Note that some forms of interrupts, or
any
> code that runs in Supervisor (Kernel, Ring 0, whatever) mode have exactly
> ZERO instances of Process "active".  Thus, code in an interrupt handler
> cannot access a Process "singleton".  If you build an OS Kernel that tries
> to make the assumption that processes can access this singleton, any
> libraries that actually *do* make use of it will be unusable within
> interrupt handlers.  The use of this particular form of "singleton" may be
> responsible for (1) the difficulty of writing (good) interrupt handlers,

and
...

read more »



Sun, 19 Oct 2003 05:52:29 GMT  
 Bug in "Move to/Namespace"?

Quote:

> You're missing one of the most obvious singleton examples:

>     A "class" is a singleton instance of its "metaclass".

I don't think I agree with this.  Just because something is globally accessible
does not mean that it is a singleton.
Quote:

> In that situation, it is quite appropriate. This is a classic aggregation
> scenario which divides object behavior into discrete
> roles/interface/protocol.

> One of the big issues in many Smalltalk implementations is misplaced
> meta-object protocol operations and state/support data. In other words,
> meta-object protocol should be in the metaclass, not its class.

> The #environment: issue that began this thread, in part, stems from this
> issue.

> ---

> However, even that responsibility structuring does not solve the general
> issue of selector-name collisions.

> That's why, when I designed SmallScript in 1998, I fully extended the basic
> namespace scoping system I had designed into QKS Smalltalk (namespace system
> designed in 1991; scoping extended in 1994).

> For our purposes here: A "scope" is a namespace (which is really a
> class/metaclass via its classPool). A message selector is a <Symbol>, which
> consists of both a canonical array of characters representing its
> family-name, and a (<Behavior>) representing its scope/namespace within that
> family. <Symbol> is a subclass of <String>. The AOS (Agents Object System)
> Platform's object model intrinsically manages character storage for all
> objects and provides WideChar and encoding as a basic object attribute for
> character storage; hence we only require a a single class for <Symbol>.

> Under this model, a selector-name to method implementation binding
> incorporates the scope information into the binding process. Thus, in
> SmallScript, every message you send has a selector-name whose scope forms
> the calling-scope.  Every method implementation has at least one message
> selector-name and may have more than one; those implementation
> selector-names also include a scope that forms the binding-scope.

> When the binder is looking for methods it chooses the best fit method based
> on matching the calling message-selector to the available method
> selector-names within the method dictionary inheritance lattice.

> Thus, set of all methods that match on the selector-name family, are then
> collated based on the scope distance between the calling message
> selector-name's scope and the candidate method implementation's
> selector-name scope. The method implementation with the shortest distance is
> the best "scope" fit; there are also other fit criteria such as argument
> type, etc.
> ============

> If the preceding was unclear, then I'll try to illustrate it with sample
> code:
> ----------------------------------------------------------------------------
> -

> "" Scoped to <IMetaprotocol>
> method class: AlterEnvViewer scope: IMetaprotocol [
> environment:
>     ...
> ].

> "" Globally scoped method -- scope <any>
> method class: AlterEnvViewer [
> environment:
>     ...
> ].

> "" Thus the following default and explicit binding can be used
> eval [
>     "" Binds based on the scopes visible to this 'eval' method
>     AlterEnvViewer environment: ...

>     "" Binds based on visibility from the <IMetaprotocol> scope
>     AlterEnvViewer#IMetaprotocol.environment: ...
> ].

> "" Or, we could use something like
> class name: NSManager imports: IMetaprotocol [
>     class-method [
>     relocateObject: subject from: srcContext to: destContext
>         ...

>         "" Here we can be confident that the #environment
>         "" message binding will use the <IMetaprotocol>
>         "" version. We are safe from other variations or
>         "" implementations that may exist in our object-space.
>         ""
>         "" Why? Because the #environment message is actually
>         "" #NSManager.private.environment:. Which has an unrolled
>         "" scope path of: {NSManager.private, NSManager, IMetaprotocol, ...}
>         ""
>         "" Which means that in searching for a best scope fit, for the
>         "" the #environment: selector-family it will bind to an
>         "" <IMetaprotocol> scoped method before scope's other than
>         "" {NSManager.private, NSManager}.
>         subject environment: ...
>         ...
>     ].
> ].

> -- Dave S.







> > >> General Solution:  Get rid of the probably useless class side
> #environment:
> > >> method and stop using the disgusting Singleton pattern, *especially*
> the
> > >> practice of replicating setters to the class side.

> > > Mark, are you talking about singletons in general, or a specific
> > > instance of a singleton pattern?

> > Both, but I'll just cover the general case and leave the rest up to your
> > imagination.

> > I have not yet seen a single "valid" use of the singleton pattern.  There
> > might be one out there somewhere, but every time I've seen one it has
> caused
> > the system to be limited in serious, fundamental ways.

> > To quote the GoF,

> > <Quote>
> > SINGLETON

> > Intent
> >     Ensure a class only has one instance, and provide a global point of
> > access to it.

> > Motivation
> >     It's important for some classes to have exactly one instance.
> Although
> > there can be many printers in a system, there should be only one printer
> > spooler.  There should be only one file system and one window manager.  A
> > digital filter will have one A/D converter.  An accounting system will be
> > dedicated to serving one company.
> > </Quote>

> > Every one of those use cases is entirely, 180 degrees wrong.  There should
> > be many printer spoolers.  There should be many file systems.  There
> should
> > be many window managers.  A digital filter must work with multiple A/D
> > converters.  Accounting systems are virtually useless when applicable to a
> > single company.

> > Printer spoolers:  Why should there be only one process per "system"
> allowed
> > to interface to printers?  Possibly to avoid contention when transmitting
> > data to a physical printer.  But that would be served *better* by having
> one
> > spooler per printer.

> > File Systems:  VisualWorks is the only system I've seen that can deal with
> > multiple file systems (and multiple file naming rules) simultaneously.  If
> > you have the right drivers you can access a file on a DOS-format disk
> > mounted on a Linux box networked to your Mac.  The only thing that allows
> > this is the *absence* of singletons in the relevant areas.

> > Window Manager:  Give me a break.  I use two monitors on my Mac (on and
> > off).  Having two window managers wouldn't be that big a deal.  In fact,
> > under Mac OS X I can have both Mac OS X and Mac OS 9 windows on the same
> > screen.  Probably implemented by writing a delegating singleton, but it
> > would be no problem normall.  Under X-Windows you should be able to have
> > multiple "servers" connect to a "client" (pardon the silly reversed
> > terminology).  The window manager "clients" should not have to run in
> > separate processes, one per connected window manager "server".

> > Digital Filter:  So you'd never want to use your filter in a mixer?  It
> > would be *IMPOSSIBLE* if you used a singleton.  You couldn't filter two
> > inputs because *THE SINGLETON'S SOLE PURPOSE IS TO PREVENT IT FROM WORKING
> > WITH TWO*.

> > Take the accounting system.  This ridiculous assumption alone must have
> cost
> > companies *billions* of dollars during mergers.  The accounting systems
> that
> > encode the organization for which they are executing in *CODE* deserve to
> be
> > as brittle as they typically are.  Programmers see their company name in
> the
> > code (or a previous name of the company!), and immediately start writing
> > their own code in such a way that it could *never* be applied in any other
> > context.  Even TopMind wouldn't advocate having a variable named
> > "number_of_BigMacs" in McDonald's accounting systems.

> > Some more examples:

> > The Windows Registry is one huge COMMON section, a table containing a
> > million global variables.  You might think "but at least they're
> > name-spaced", but that's only in the sense that a COBOL data area has
> > name-spaces.

> > The Mac Desktop file (or its current incarnation) is not much better
> (well,
> > at least you can rebuild it from the applications without having to run
> > thousands of installers).  Ah, but on the Mac each volume has its own
> > Desktop file.

> > Multiprocessors break some programs' assumption that there is only one
> > processor.  Fortunately, this particular assumption will induce "bit rot"
> in
> > programs that make it, as multiprocessor systems gradually become more
> > common, then ubiquitous.

> > Even in hardware, singleton fallacies are gradually disappearing.  I don't
> > remember the manufacturer (probably SGI), but on some systems they don't
> > even have a single data bus (let alone a single processor).  A "Crossbar
> > Bus", if I recall, allowing the components to communicate in K concurrent
> > two-party data transfers.

> > The only singleton that makes sense to me is the current Process (not
> > thread).  But again, that assumes a memory architecture in which only one
> > Process's address space is visible.  This is not true of systems, say,
> > running the 603e PowerPC processor (if memory serves).  That system had
> page
> > protection but no virtual-to-physical address translation.  Thus, every
> > process had the same "address space" but the processes could only see
> > mutually

...

read more »



Sun, 19 Oct 2003 06:17:32 GMT  
 Bug in "Move to/Namespace"?


Quote:


> > There are valid uses of singleton, in VisualWorks nil, true and false
> > are the obvious examples.

> Why should nil be a singleton?  I can come up with some examples where I
> wish it wasn't, and I have to "work around" the system to compensate.

> Actually, this is one I wouldn't mind David Simmons commenting on.

This is a bit far from the original problem.

I.e., the original problem was not actually caused by the use of a
"singleton" pattern, but rather by a much more general problem of message
selector-name collisions. It is a highly probable situation that over time
two (probably-unrelated) parties will develop bodies of code which use the
same message-selector for semantically unrelated purposes.

Without namespace scoping of message selector-names this is clearly
problematic (and is detrimental to generalized design for re-use).

Static languages, such as C++, addressed this problem through the use of
namespaces at compile time.

However, dynamic languages cannot adequately address the problem at compile
time because it is not possible to resolve the receiver and argument types
statically.

Therefore, dynamic languages must perform their scope resolution at
invocation time. There is *no* performance penalty for providing this
feature in a dynamic language assuming you've thought out design space for
the virtual machine and its object model.
=======

As to the specific question of <nil> being a singleton, I would first ask
what are the problems caused by <nil> being a singleton.

I've not seen any in all my years with Smalltalk. I suspect that if you are
having some problems relating to <nil> the problem does not lie with <nil>
or the general notion of const (canonically unique) values but rather with
ill-designed frameworks that are designed based on OO "behavorial" semantics
but implemented using procedural/algol/functional "value" semantics or
vice-versa.  (I.e., tests for specific a const "value" is a different thing
from a test for a group of supported "behavior" (a role/interface)).

To me, the concept of <nil>, <true>, <false>, et cetera is no different than
the notion that <Symbol> instances are canonical literals (singleton
values), as are [in SmallScript and QKS Smalltalk] #(...) <Array> consts,
'...' <String> consts, or #{...} <GUID> uuid consts.

As to whether or not one should be able to create instances of
<UndefinedObject>, that is yet another question. I.e., <nil> is a
pseudo-variable const defined by the Smalltalk language. The language does
not explicitly state whether or not <UndefinedObject> may instantiate
additional instances, but, even if it did, they would not be <nil>.

In SmallScript and QKS Smalltalk, the <UndefinedObject> class has its
instantiation constructor property set to <false>; therefore it will
generate an exception if an instantiation is attempted. However, if you turn
that property back on and make a new instance, the <UndefinedObject> class
implements the behavior that is supported by <nil> [it's just not especially
optimized by the implementation].

"" Note the following:
nil = UndefinedObject new. "" Is <false>
---

At a language definition level, <nil> and other pseudo-variable const values
play a fundamental role in the core language and its frameworks.

Knowing that the language defines them as const values enables an
implementation to "safely/consistently" treat them (the pseudo-variables but
not necessarily other instances of their same class) as singletons. Which in
turns enables fast implementation optimizations based on identity testing in
generated machine code.
---

Does this help?

-- Dave S.

Quote:

> --

> Nevin Pratt

> http://www.smalltalk.org/consultants.html
> (801) 455-1839, (801) 292-7804



Sun, 19 Oct 2003 06:26:39 GMT  
 Bug in "Move to/Namespace"?

Quote:


> > You're missing one of the most obvious singleton examples:

> >     A "class" is a singleton instance of its "metaclass".

> I don't think I agree with this.  Just because something is globally
accessible
> does not mean that it is a singleton.

Where did the "globally" accessible notion come in.

I didn't use it. There is no direct relationship between a "singleton" and
the idea of a "global" -- read on below.

A singleton, in the OO context, only implies that there is *one* and *only
one* instance of a given class or value-set.  The "value-set" means only one
instance of a given class with a particular value/set-of-fields. Examples of
this would be <Symbol> instances or <SmallInteger> instances, <Character>
instances, etc.

The concept of "global" has to do with access/binding-scope and is
orthogonal to the concept of what a singleton is. It just happens that many
people who create (global and otherwise) variables, will initialize them
using const values, which are often "singletons".

I find that the use of "global", as with notions of "public" and
"protected", is a generally bogus way to design/view a problem space.

Scope resolution:
----------------
A given context has things it exports and things it imports. It may import
elements explicitly or implicitly via other explicit declarations.

If a context exports things and it is the "single" top-level/root of a scope
lattice then all its exports are "global". But, one should view them as
implicit imports into all the subscopes of the lattice; not as "global"
values.
---

Furthermore, this should be distinguished from language level operators and
keyword constructs. Which, do indeed, define canonical literals (const)
values.

The use of these language construct values, in and of themselves, does not
indicate that they are singletons within their OO behavior/constructor
class.

In most cases, by explicit other rules in the language, they may in fact be
constructor-value-singletons. What the language does specify is that
"canonical" literal const declaration constructs will result in the same
single-unique-const value when compared with the same declaration construct
in some other expression (active namespace scope of the context may affect
implicit elements of a declaration).

    'Foo' == 'Foo'.
    'Foo' copy !== 'Foo'.

    #bar == #bar.

    nil == nil.
    nil !== UndefinedObject new. "" Maybe, maybe not.
                                 "" #new may generate an exception

-- Dave S.

Quote:

> > In that situation, it is quite appropriate. This is a classic
aggregation
> > scenario which divides object behavior into discrete
> > roles/interface/protocol.

> > One of the big issues in many Smalltalk implementations is misplaced
> > meta-object protocol operations and state/support data. In other words,
> > meta-object protocol should be in the metaclass, not its class.

> > The #environment: issue that began this thread, in part, stems from this
> > issue.

> > ---

> > However, even that responsibility structuring does not solve the general
> > issue of selector-name collisions.

> > That's why, when I designed SmallScript in 1998, I fully extended the
basic
> > namespace scoping system I had designed into QKS Smalltalk (namespace
system
> > designed in 1991; scoping extended in 1994).

> > For our purposes here: A "scope" is a namespace (which is really a
> > class/metaclass via its classPool). A message selector is a <Symbol>,
which
> > consists of both a canonical array of characters representing its
> > family-name, and a (<Behavior>) representing its scope/namespace within
that
> > family. <Symbol> is a subclass of <String>. The AOS (Agents Object
System)
> > Platform's object model intrinsically manages character storage for all
> > objects and provides WideChar and encoding as a basic object attribute
for
> > character storage; hence we only require a a single class for <Symbol>.

> > Under this model, a selector-name to method implementation binding
> > incorporates the scope information into the binding process. Thus, in
> > SmallScript, every message you send has a selector-name whose scope
forms
> > the calling-scope.  Every method implementation has at least one message
> > selector-name and may have more than one; those implementation
> > selector-names also include a scope that forms the binding-scope.

> > When the binder is looking for methods it chooses the best fit method
based
> > on matching the calling message-selector to the available method
> > selector-names within the method dictionary inheritance lattice.

> > Thus, set of all methods that match on the selector-name family, are
then
> > collated based on the scope distance between the calling message
> > selector-name's scope and the candidate method implementation's
> > selector-name scope. The method implementation with the shortest
distance is
> > the best "scope" fit; there are also other fit criteria such as argument
> > type, etc.
> > ============

> > If the preceding was unclear, then I'll try to illustrate it with sample
> > code:

> --------------------------------------------------------------------------
--
> > -

> > "" Scoped to <IMetaprotocol>
> > method class: AlterEnvViewer scope: IMetaprotocol [
> > environment:
> >     ...
> > ].

> > "" Globally scoped method -- scope <any>
> > method class: AlterEnvViewer [
> > environment:
> >     ...
> > ].

> > "" Thus the following default and explicit binding can be used
> > eval [
> >     "" Binds based on the scopes visible to this 'eval' method
> >     AlterEnvViewer environment: ...

> >     "" Binds based on visibility from the <IMetaprotocol> scope
> >     AlterEnvViewer#IMetaprotocol.environment: ...
> > ].

> > "" Or, we could use something like
> > class name: NSManager imports: IMetaprotocol [
> >     class-method [
> >     relocateObject: subject from: srcContext to: destContext
> >         ...

> >         "" Here we can be confident that the #environment
> >         "" message binding will use the <IMetaprotocol>
> >         "" version. We are safe from other variations or
> >         "" implementations that may exist in our object-space.
> >         ""
> >         "" Why? Because the #environment message is actually
> >         "" #NSManager.private.environment:. Which has an unrolled
> >         "" scope path of: {NSManager.private, NSManager, IMetaprotocol,
...}
> >         ""
> >         "" Which means that in searching for a best scope fit, for the
> >         "" the #environment: selector-family it will bind to an
> >         "" <IMetaprotocol> scoped method before scope's other than
> >         "" {NSManager.private, NSManager}.
> >         subject environment: ...
> >         ...
> >     ].
> > ].

> > -- Dave S.







> > > >> General Solution:  Get rid of the probably useless class side
> > #environment:
> > > >> method and stop using the disgusting Singleton pattern,
*especially*
> > the
> > > >> practice of replicating setters to the class side.

> > > > Mark, are you talking about singletons in general, or a specific
> > > > instance of a singleton pattern?

> > > Both, but I'll just cover the general case and leave the rest up to
your
> > > imagination.

> > > I have not yet seen a single "valid" use of the singleton pattern.
There
> > > might be one out there somewhere, but every time I've seen one it has
> > caused
> > > the system to be limited in serious, fundamental ways.

> > > To quote the GoF,

> > > <Quote>
> > > SINGLETON

> > > Intent
> > >     Ensure a class only has one instance, and provide a global point
of
> > > access to it.

> > > Motivation
> > >     It's important for some classes to have exactly one instance.
> > Although
> > > there can be many printers in a system, there should be only one
printer
> > > spooler.  There should be only one file system and one window manager.
A
> > > digital filter will have one A/D converter.  An accounting system will
be
> > > dedicated to serving one company.
> > > </Quote>

> > > Every one of those use cases is entirely, 180 degrees wrong.  There
should
> > > be many printer spoolers.  There should be many file systems.  There
> > should
> > > be many window managers.  A digital filter must work with multiple A/D
> > > converters.  Accounting systems are virtually useless when applicable
to a
> > > single company.

> > > Printer spoolers:  Why should there be only one process per "system"
> > allowed
> > > to interface to printers?  Possibly to avoid contention when
transmitting
> > > data to a physical printer.  But that would be served *better* by
having
> > one
> > > spooler per printer.

> > > File Systems:  VisualWorks is the only system I've seen that can deal
with
> > > multiple file systems (and multiple file naming rules) simultaneously.
If
> > > you have the right drivers you can access a file on a DOS-format disk
> > > mounted on a Linux box networked to your Mac.  The only thing that
allows
> > > this is the *absence* of singletons in the relevant areas.

> > > Window Manager:  Give me a break.  I use two monitors on my Mac (on
and
> > > off).  Having two window managers wouldn't be that big a deal.  In
fact,
> > > under Mac OS X I can have both Mac OS X and Mac OS 9 windows on the
same
> > > screen.  Probably implemented by writing a delegating singleton, but
it
> > > would be no problem normall.  Under X-Windows you should be able to
have

...

read more »



Sun, 19 Oct 2003 06:55:38 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. "namespace import": bug or feature?

2. BUGS?: Tcl8 "namespace" quirks

3. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

4. PTUI problem, "lifo::lifo": unknown namespace

5. "load" into namespace

6. Why no "namespace exists"

7. require/provide and "unknown" namespace fix

8. Creating "virtual" module-namespace

9. "Tracks" when moving lines

10. Moving Image with "hand" icon

11. "Moving" objects of limited type

12. move to field "justified LEFT"

 

 
Powered by phpBB® Forum Software