Instance

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Instance

jlm@justinfront.net
Since much of web creation deals with single instances, and multiple  
classes are often in reality a rarity, it would make sense rather than  
to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

        public function new()
        {
                // only allowed to construct once throws an error if you try to pass  
parameters to constructor more than once
        }

}

instance Fred initialise many
{

        public function new()
        {
                // allowed to reconstruct add a destroy if relevant here, has a  
_first parameter to test against or something??
        }

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't  
bother with setting up a singleton partly because they are not sure of  
best syntax and its more effort that is rarely needed.  This syntax  
would encourage people to be clear when there is only one instance in  
a system and it seems sensible?  I rarely bother with Singletons but  
they are helping me make sure I only have one video running,  
( close()  also helps! ).  I really don't see why they are not inbuilt  
in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

John A. De Goes

There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

jlm@justinfront.net
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Ian Liu Rodrigues
What is the problem with singleton? ;)

I guess too much people worry too much about syntax sugar,
or maybe I am suspicious to say this, because I work with C
and Gtk!

When I work with Singletons in haXe I do this:

class Single {
    private static var instance:Single;
    public static function getInstance() {
        if (instance == null)
            instance = new Single();
        return instance;
    }

    private function new() {
        trace("Singleton created!");
    }
}

Now its as easy as calling Single.getInstance()

Cheers,
Ian L.

On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills <[hidden email]> wrote:
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

jlm@justinfront.net
But do you use that every time or only if you are sure it might be needed... my point it is a simple concept that for me is at the language level and if a language is sweet it seems like it  should really be part of it, if it is always similar.  I also wonder that if we consider it and its implementation it may lead to other simplicities, but that is more a feeling ( I am intuitive coder! )


On 11 Sep 2009, at 02:30, Ian Liu wrote:

What is the problem with singleton? ;)

I guess too much people worry too much about syntax sugar,
or maybe I am suspicious to say this, because I work with C
and Gtk!

When I work with Singletons in haXe I do this:

class Single {
    private static var instance:Single;
    public static function getInstance() {
        if (instance == null)
            instance = new Single();
        return instance;
    }

    private function new() {
        trace("Singleton created!");
    }
}

Now its as easy as calling Single.getInstance()

Cheers,
Ian L.

On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills <[hidden email]> wrote:
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Nek
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Nek
Sorry. I can't see your point here.
Why use a special language construct for some design pattern. Yes, patterns happen to be here and there... but that doesn't mean they should be implemented on language's basis level. It would be mix of two different scales. Such a move will make things unclear.

I like syntactic sugar when it could be implemented with tools provided by the language itself. In most other cases it's evil.

But do you use that every time or only if you are sure it might be needed... my point it is a simple concept that for me is at the language level and if a language is sweet it seems like it  should really be part of it, if it is always similar.  I also wonder that if we consider it and its implementation it may lead to other simplicities, but that is more a feeling ( I am intuitive coder! )


On 11 Sep 2009, at 02:30, Ian Liu wrote:

What is the problem with singleton? ;)

I guess too much people worry too much about syntax sugar,
or maybe I am suspicious to say this, because I work with C
and Gtk!

When I work with Singletons in haXe I do this:

class Single {
    private static var instance:Single;
    public static function getInstance() {
        if (instance == null)
            instance = new Single();
        return instance;
    }

    private function new() {
        trace("Singleton created!");
    }
}

Now its as easy as calling Single.getInstance()

Cheers,
Ian L.

On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills <[hidden email]> wrote:
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Benjamin Dasnois
I agree with Nikita and don't see any need to specify at the language
level (nor maybe even at the code level) that I have a singleton.

On Fri, Sep 11, 2009 at 5:04 AM, Nikita Dudnik <[hidden email]> wrote:

> Sorry. I can't see your point here.
> Why use a special language construct for some design pattern. Yes, patterns
> happen to be here and there... but that doesn't mean they should be
> implemented on language's basis level. It would be mix of two different
> scales. Such a move will make things unclear.
>
> I like syntactic sugar when it could be implemented with tools provided by
> the language itself. In most other cases it's evil.
>
> But do you use that every time or only if you are sure it might be needed...
> my point it is a simple concept that for me is at the language level and if
> a language is sweet it seems like it  should really be part of it, if it is
> always similar.  I also wonder that if we consider it and its implementation
> it may lead to other simplicities, but that is more a feeling ( I am
> intuitive coder! )
>
> On 11 Sep 2009, at 02:30, Ian Liu wrote:
>
> What is the problem with singleton? ;)
>
> I guess too much people worry too much about syntax sugar,
> or maybe I am suspicious to say this, because I work with C
> and Gtk!
>
> When I work with Singletons in haXe I do this:
>
> class Single {
>     private static var instance:Single;
>     public static function getInstance() {
>         if (instance == null)
>             instance = new Single();
>         return instance;
>     }
>
>     private function new() {
>         trace("Singleton created!");
>     }
> }
>
> Now its as easy as calling Single.getInstance()
>
> Cheers,
> Ian L.
>
> On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills
> <[hidden email]> wrote:
>>
>> Well to me
>> Fred.INSTANCE()
>> looks messy and hacky.
>> It is a common in web dev to have most classes being single instances and
>> I have read that the current belief in classes is slightly misplaced while
>> languages and libraries being generic need classes, applications using them
>> are often specific and under fast deadlines so instances often make more
>> sense especially where garbage is a problem so reuse is good.
>> Built in support would be nice.
>> Cheers
>> ;j
>> On 11 Sep 2009, at 00:34, John A. De Goes wrote:
>>
>> There's no need for an extension.
>> Simply:
>>
>> class Fred {
>>     public static var INSTANCE:Fred = new Fred();
>>
>>     private function new() { }
>> }
>>
>> For a language with built in support for singletons, see Scala. In Haxe
>> such a thing might look like:
>>
>> object Fred {
>>     // methods/fields go here, they're all access by Fred.XXX
>> }
>>
>> Regards,
>> John
>> On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:
>>
>> Since much of web creation deals with single instances, and multiple
>> classes are often in reality a rarity, it would make sense rather than to
>> use a Singleton construction to instead have an 'Instance'.
>>
>> instance Fred initialise 1
>> {
>>
>> public function new()
>> {
>> // only allowed to construct once throws an error if you try to pass
>> parameters to constructor more than once
>> }
>>
>> }
>>
>> instance Fred initialise many
>> {
>>
>> public function new()
>> {
>> // allowed to reconstruct add a destroy if relevant here, has a _first
>> parameter to test against or something??
>> }
>>
>> }
>>
>> I am not sure if 'instance' would increase overhead?...but...
>>
>> This would add a lot of clarity to the language, often users don't bother
>> with setting up a singleton partly because they are not sure of best syntax
>> and its more effort that is rarely needed.  This syntax would encourage
>> people to be clear when there is only one instance in a system and it seems
>> sensible?  I rarely bother with Singletons but they are helping me make sure
>> I only have one video running, ( close()  also helps! ).  I really don't see
>> why they are not inbuilt in languages?  But I am sometimes nieve about such
>> things :)
>>
>>
>>
>> Cheers
>>
>> ;j
>>
>>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Armén
In reply to this post by John A. De Goes
n Fri, Sep 11, 2009 at 01:34, John A. De Goes <[hidden email]> wrote:
>
> For a language with built in support for singletons, see Scala. In Haxe such
> a thing might look like:
>
> object Fred {
>     // methods/fields go here, they're all access by Fred.XXX
> }

Already implemented:

var Fred = {
field1: //...
field2: //
};

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Tyler MacLeod
In reply to this post by Nek
I'm sorry, I'm just trying to follow along and your argument me has me confused. What are the two different scales you mean? Do you mean like different levels of abstraction?

Do you consider the for ... in shortcut for the iterator pattern to be unclear? I know it was the first time I saw it, but as I started using it, it became quite natural for me.

You say you like the syntactic sugar when it "could be implemented with tools provided by the language itself." I don't believe I understand that sentence. Is that not what is being discussed here?

-- Tyler MacLeod


On Fri, Sep 11, 2009 at 12:04 AM, Nikita Dudnik <[hidden email]> wrote:
Sorry. I can't see your point here.
Why use a special language construct for some design pattern. Yes, patterns happen to be here and there... but that doesn't mean they should be implemented on language's basis level. It would be mix of two different scales. Such a move will make things unclear.

I like syntactic sugar when it could be implemented with tools provided by the language itself. In most other cases it's evil.


But do you use that every time or only if you are sure it might be needed... my point it is a simple concept that for me is at the language level and if a language is sweet it seems like it  should really be part of it, if it is always similar.  I also wonder that if we consider it and its implementation it may lead to other simplicities, but that is more a feeling ( I am intuitive coder! )


On 11 Sep 2009, at 02:30, Ian Liu wrote:

What is the problem with singleton? ;)

I guess too much people worry too much about syntax sugar,
or maybe I am suspicious to say this, because I work with C
and Gtk!

When I work with Singletons in haXe I do this:

class Single {
    private static var instance:Single;
    public static function getInstance() {
        if (instance == null)
            instance = new Single();
        return instance;
    }

    private function new() {
        trace("Singleton created!");
    }
}

Now its as easy as calling Single.getInstance()

Cheers,
Ian L.

On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills <[hidden email]> wrote:
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Nek
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Nek
The scales of software system organization. Let's say you want to build a brick house. There are many different low level parts you use: bricks, window frames, door frames. That's base "house building language" features.
At some point you have built your house, then you've built one more, and more... Suddenly you realize every house you have built has one entrance with stairs. You even call it some special name "singleton". :)
But does it justify "singleton" should ship to you as one solid part? I don't think so.
Let's get back to something real ) On the language level implementation of singleton keyword doesn't add to overall expressiveness of the haxe and makes it bloated with built in construction of architectural level for a really specific situation.
Also it's well and long known singletons are evil ;)  http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx
Yet I could justify singletons on the framework level. For example there is PureMVC and it's great.

Talking about the for ... in shortcut you've mentioned it's not the iterator pattern. It's just a built in language statement to work with built in data types.
Iterator Pattern on wikipedia: http://en.wikipedia.org/wiki/Iterator_pattern

And talking about "could be implemented with tools provided by the language itself."
Take a look at LISP. It's most popular highly extensible languages. Lets you define your own operators. Saying the truth I don't know is there anything else such powerful.
http://www.bookshelf.jp/texi/onlisp/onlisp_2.html
Ruby is extensible too and it's got hype this days.
http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp

Hope it clarifies and enlightens.

I feel I've said too much. Still I want to talk about DSLs, metaprogramming. Gotta stop. )

Nikita Dudnik

I'm sorry, I'm just trying to follow along and your argument me has me confused. What are the two different scales you mean? Do you mean like diffIf you eally erent levels of abstraction?

Do you consider the for ... in shortcut for the iterator pattern to be unclear? I know it was the first time I saw it, but as I started using it, it became quite natural for me.

You say you like the syntactic sugar when it "could be implemented with tools provided by the language itself." I don't believe I understand that sentence. Is that not what is being discussed here?

-- Tyler MacLeod


On Fri, Sep 11, 2009 at 12:04 AM, Nikita Dudnik <[hidden email]> wrote:
Sorry. I can't see your point here.
Why use a special language construct for some design pattern. Yes, patterns happen to be here and there... but that doesn't mean they should be implemented on language's basis level. It would be mix of two different scales. Such a move will make things unclear.

I like syntactic sugar when it could be implemented with tools provided by the language itself. In most other cases it's evil.


But do you use that every time or only if you are sure it might be needed... my point it is a simple concept that for me is at the language level and if a language is sweet it seems like it  should really be part of it, if it is always similar.  I also wonder that if we consider it and its implementation it may lead to other simplicities, but that is more a feeling ( I am intuitive coder! )


On 11 Sep 2009, at 02:30, Ian Liu wrote:

What is the problem with singleton? ;)

I guess too much people worry too much about syntax sugar,
or maybe I am suspicious to say this, because I work with C
and Gtk!

When I work with Singletons in haXe I do this:

class Single {
    private static var instance:Single;
    public static function getInstance() {
        if (instance == null)
            instance = new Single();
        return instance;
    }

    private function new() {
        trace("Singleton created!");
    }
}

Now its as easy as calling Single.getInstance()

Cheers,
Ian L.

On Thu, Sep 10, 2009 at 8:53 PM, Justin Lawerance Mills <[hidden email]> wrote:
Well to me 

Fred.INSTANCE() 

looks messy and hacky.

It is a common in web dev to have most classes being single instances and I have read that the current belief in classes is slightly misplaced while languages and libraries being generic need classes, applications using them are often specific and under fast deadlines so instances often make more sense especially where garbage is a problem so reuse is good.

Built in support would be nice.

Cheers

;j

On 11 Sep 2009, at 00:34, John A. De Goes wrote:


There's no need for an extension.

Simply:

class Fred {
    public static var INSTANCE:Fred = new Fred();

    private function new() { }
}

For a language with built in support for singletons, see Scala. In Haxe such a thing might look like:

object Fred {
    // methods/fields go here, they're all access by Fred.XXX
}

Regards,

John

On Sep 10, 2009, at 5:15 PM, Justin Lawerance Mills wrote:

Since much of web creation deals with single instances, and multiple classes are often in reality a rarity, it would make sense rather than to use a Singleton construction to instead have an 'Instance'.

instance Fred initialise 1
{

public function new()
{
// only allowed to construct once throws an error if you try to pass parameters to constructor more than once
}

}

instance Fred initialise many
{

public function new()
{
// allowed to reconstruct add a destroy if relevant here, has a _first parameter to test against or something??
}

}

I am not sure if 'instance' would increase overhead?...but...

This would add a lot of clarity to the language, often users don't bother with setting up a singleton partly because they are not sure of best syntax and its more effort that is rarely needed.  This syntax would encourage people to be clear when there is only one instance in a system and it seems sensible?  I rarely bother with Singletons but they are helping me make sure I only have one video running, ( close()  also helps! ).  I really don't see why they are not inbuilt in languages?  But I am sometimes nieve about such things :)



Cheers

;j




--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Gamehaxe
In reply to this post by Ian Liu Rodrigues
Hi
No one *wants* to use a singleton.
Syntactically it is just pain, pain and more pain.  It is the
library punishing you and your keyboard for for it's own slackness.

Consider:

class Single {

       var someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder :  
X;

      private static var instance:Single;
      public static function getInstance() {
          if (instance == null)
              instance = new Single();
          return instance;
      }


      public function doSomethingUseful  {
         return  
someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder.x;
      }


      private function new() {
          someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder =  
new X();
      }
}

With usage:

    Single.getInstance().doSomethingUseful();


Vs:

class Single {

      static var  
someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder : X;

      static public function doSomethingUseful  { // NOTE: static
         init();
         return  
someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder.x;
      }


      static private function init() {
          if  
(someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder==null)
          someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder =  
new X();
      }
}


With usage:

    Single.doSomethingUseful();

compare:

    Single.getInstance().doSomethingUseful();


So, the trade off is:
Each static method DEFINITION needs an "init()" call vs.
each method CALL needs a getInstance() call.

Now CALLS >= DEFINITIONS, so there is less typing for a "simple, static"  
option.

If initization order id not a problem (ie, no singltons calling other
singltons in constructors, you may get away without the init function:
static var someCriticalVariableThatNeedsToBeInitilaisedInTheCorrectOrder =  
new X();


If you are after language features, then something interesting might be
a special "prologue" function that gets automatically inserted at the
beginning of each static/non static function in a class - this would also  
be useful for
profiling/debuging etc, as well as the "init()" call.

I simply can't unserstand why a class user would want to type:
"Single.getInstance().doSomethingUseful();" instead of  
"Single.doSomethingUseful();"
can anyone explain this to me?  It completely baffles me.

Hugh














--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

clemos
On Sat, Sep 12, 2009 at 4:42 AM, Hugh Sanderson <[hidden email]> wrote:

<snip>

> I simply can't unserstand why a class user would want to type:
> "Single.getInstance().doSomethingUseful();" instead of
> "Single.doSomethingUseful();"
> can anyone explain this to me?  It completely baffles me.

In my experience, using singletons instead of static classes is useful
because class instances allow inheritance while static classes don't.
++++++++
Clément

> Hugh
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Gamehaxe
Clément,
I think this is very reasonable when you are not using the "singleton  
pattern",
ie, you store your interface in a varible to allow switching on  
implementations, eg:

class Renderer
{
    // base class function
    public function Render(....) { }

    static public function getSoftwareRenderer() : Renderer;
    static public function getHardwareRenderer() : Renderer;
}

But I would not use this like this:

    Renderer.getSoftwareRenderer().Render( ... )

I would use it like this:

    var renderer = doHardwareRender ? Renderer.getHardwareRenderer() :  
Renderer.getSoftwareRenderer();

    renderer.Render(...);
    renderer.Render(...);
    renderer.Render(...);
    renderer.Render(...);

Which is clearly better than statics.
But if you are just after "A single, global set of constant functions",  
the statics
still win - event with inheritance:


class Renderer
{
    public function Render(....) { }

    static public function getInstance() : Renderer
    {
       return new OptimizedRenderer(); <------ Use inheritance here
    }
}

class OptimisedRenderer extends Renderer
{
    public override function Render(....) { /* Do it fast */ }
}


    Renderer.getInstance().Render(...);
    Renderer.getInstance().Render(...);
    Renderer.getInstance().Render(...);
    Renderer.getInstance().Render(...);
    Renderer.getInstance().Render(...);


You can still use statics:


class Renderer
{
    public static function Render(....)
    {
       init();
       mRenderer->Render(.....)
    }

    static function init()
    {
       mRenderer = new OptimizedRenderer(); <------ Use inheritance here
    }
}

    // Much nicer !
    Renderer.Render(...);
    Renderer.Render(...);
    Renderer.Render(...);
    Renderer.Render(...);
    Renderer.Render(...);
    Renderer.Render(...);


I guess I object to the user-code use of redundant "getInstance()".
Obviously interface pointers are pretty nifty - I use that pattern all the  
time.

Hugh



>> I simply can't unserstand why a class user would want to type:
>> "Single.getInstance().doSomethingUseful();" instead of
>> "Single.doSomethingUseful();"
>> can anyone explain this to me?  It completely baffles me.
>
> In my experience, using singletons instead of static classes is useful
> because class instances allow inheritance while static classes don't.
> ++++++++
> Clément
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

back2dos
In reply to this post by clemos
Hey guys,

You might find this blog post interesting:
http://steve.yegge.googlepages.com/singleton-considered-stupid

To recap in a few words and add some thoughts of mine:

singletons are bad. By "singletons" I mean "singletons the way they are
used most of the time". They are an anti-pattern, that will always
seduce you to throw good OO approaches overboard. If you use singletons,
ANY code relying on them will have dependancies, and the more you use
them, the more you will completely destroy any notion of object
hierarchy within your code.
I know, it's boring, but really, if an object needs access to another
object, then do yourself the favour, and pass it as a parameter when you
initalize it. It's a little more writing, but it's much more flexible.
And also, your lazyness will force you to find a different solution,
reducing overall dependancies in your implementation ... :)
What Hugh describes is just using global functions grouped into
pseudo-namespaces. That's cool, for utitlity functions, etc.. But if
they are methods of a static/global statefull class object, it becomes
harmfull, in my point of view. Avoid using any global access to stateful
entities. Have a clear hierachy, and pass the least possible information
from the top (root class, with some boot and glue code) to the bottom
(dumb, but reusable components).

The actual singleton is only a mechanism to ensure a certain object is
instantiated only once. In my point of view getInstance() should throw
an error when called a second time, since if you have a clear object
hierarchy and initialization sequence, there is no need for more than
one call.
It is not the point of singletons, that you can access some object from
anywhere. Thus it is not meaningful to compare:

    Single.getInstance().doSomethingUseful();//which is bad style, in my
eyes
        vs.
    Single.doSomethingUseful();//ok, if this is a global function, and
not a static method
 
but rather

    var s = Single.getInstance();
        vs.
    var s = new Single();

The singleton exposes a different interface for instantiation than
classical classes do.
To me, the only purpose of singletons is a way to point out to myself
(and later maybe others) that a given object should be instantiated only
once. In the end, converting regular classes to singletons is really
just a refactoring task, so I think there is no point in introducing
this Scala feature, since it only saves you about 3-6 lines per object
and would only lead to people using it the wrong way, resulting in a lot
of unflexible code.

greetz
back2dos

clemos wrote:

> On Sat, Sep 12, 2009 at 4:42 AM, Hugh Sanderson <[hidden email]> wrote:
>
> <snip>
>
>> I simply can't unserstand why a class user would want to type:
>> "Single.getInstance().doSomethingUseful();" instead of
>> "Single.doSomethingUseful();"
>> can anyone explain this to me?  It completely baffles me.
>
> In my experience, using singletons instead of static classes is useful
> because class instances allow inheritance while static classes don't.
> ++++++++
> Clément
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

Gamehaxe
Yes, I would have to agree with this - I would only use a "singleton"
for global functions in langages that deam that you should not have global
functions.
In other languages (ie, c++), I make the functions global, and put
the "state" in the .cpp file (thus not polluting the header, and
allowing me to change the implementation without any possible
chance of anything else knowing I have done so).
A specific example: in the hxcpp backend, each class registers
itself using a global function so you can iterate over all the
classes.  The initialization and handling of this list is taken
care of in the cpp file.
So I agree, pseudo-global functions only - but sometimes you do need them.

Hugh

>  You might find this blog post interesting:  
> http://steve.yegge.googlepages.com/singleton-considered-stupid



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Instance

back2dos
well, when it comes to "magic", in your example what holds together the
runtime environement, this is necessary, but it's not a good aproach for
designing applications ... :)

Hugh Sanderson wrote:
>
> So I agree, pseudo-global functions only - but sometimes you do need
> them.
>
> Hugh
>

--
haXe - an open source web programming language
http://haxe.org