Opinions on "new SomeObject" vs. "SomeObject->new()"

[Matija Papec]

X-Ftn-To: Lack Mr G M

my $tko1 = MyToken->from_token('token' => $token);
my $tko2 = MyToken->via_login('id' => yourid, 'password' => yourpassword);

Some poeple seem to be advocating this conveying more:

my $tko1 = from_token MyToken('token' => $token);
my $tko2 = via_login MyToken('id' => yourid, 'password' => yourpassword);

I can't see it myself.

Isn't your last example potentially troublesome in case of class
inheritance?

 

[Steve Grazzini]

Isn't your last example potentially troublesome in case of class
inheritance?

No.

It's troublesome if there are functions in the current package
called from_token() or via_login(). This has nothing to do with
constructors or inheritance -- it's a parsing issue. Indirect
object syntax is ugly and ambiguous and the parser doesn't always
get it right.

 

[Iain Truskett]

* Quantum Mechanic <[email protected]>:

[...]

Not to put too fine a point on it, but what is acceptable syntax for
creating a new instance of a class of a given instance, when that
class isn't known at the time of coding? [...]
If I don't know the class ahead of time (determined at runtime, for
instance), I'm looking at one of these:

$new_instance = new $old_instance;

$new_instance = $old_instance->new();

$new_instance = (ref $old_instance)->new();

Or even:
my @classes = qw( Class Fnord Fnerk Xyzzy );
my $class = $classes[ rand @classes ];
my $new_instance = $class->new();



cheers,

 

[pkent]

Except that it is actually:

$new_object = new Class;

and you are *not* asking for a new class.

No, but imagine a better example that uses a slightly better name, like
where I have a class representing Employees. To create a new instance of
an employee I can say:

my $scott = new Employee( Password => 'tiger' );
or of course:
my $scott = Employee->new( Password => 'tiger' );

So in that less abstract example I'm not asking for a new _class_, I'm
asking for a new employee, i.e. a new thing of a certain kind. But at
least with perl you can choose the syntax that you prefer, or that makes
most sense in a given application (like the login tokens example you
give) - you probably can't have one hard and fast rule for every single
case.

Also the use of 'new' as a constructor is just a common convention, but
my constructor can be called anything:

my $scott = existing Employee( ID => '211' );

It's probably terrible to suggest that constructors need not be methods
at all, but could in fact be plain routines:

my $scott = Employee::existing( ID => '211' );
# $scott is an object

but you can do it - there are reasons not to do it

P

 

[Matija Papec]

X-Ftn-To: Abigail

<> which should have community consensus? Like perlstyle.pod which could make
<> some guidelines more official?

Please no. *Personal* programming guidelines are ok. But let's not wade
into the swamps of trying to derive guidelines with community consensus.
Remember that are hundreds of thousands of Perl programmers, but only a
few hundred of them are active on Perl forums - but there are dozens of
those forums.

Ok, a whole community is too wide for such task, but actually I had in mind
smaller group of highly experienced programmers/teachers which can receive
blessings from Larry. Of course, if such guidelines threaten some basic
religious beliefs, they can never be done.

style guide". If you want a language that comes with a notion on what
is good style, and what should be avoided, you find it thataway --->
www.python.org.

There is a difference between enforced standards and guidelines which you
use willingly. Also, freedom is a great thing but first you have to
//understand// implications of your programming decisions. If you're not
sure what you're doing, better grab some guide which will tell you how and
why (otherwise fully enjoy your freedom).
So, how much evil I am, is there some hope for me?

 

[Iain Truskett]

* Matija Papec <[email protected]>:

[...]

There is a difference between enforced standards and
guidelines which you use willingly. Also, freedom is a
great thing but first you have to //understand//
implications of your programming decisions.

Perhaps you could draw up a list of guidelines, where for
every guideline you also have a counter-guideline or three.

Let people see what other people consider good practice and
pick and mix between them =)


cheers,

 

[Matija Papec]

X-Ftn-To: Iain Truskett

Perhaps you could draw up a list of guidelines, where for
every guideline you also have a counter-guideline or three.

Let people see what other people consider good practice and
pick and mix between them =)

Ok, I'll write first commandment,

1) do "use strict;" in /all/ your programs until you learn from perldoc
strict. You are also free to continue such practice after this revelation.
(there is no counter-commandment for this one )