strictly no indirect object syntax?

Yuval Kogman schrieb:
Fri, Jul 04, 2008 at 08:13:35 +0200, H.Merijn Brand wrote:

>I'm prepared to alter all my code for this to
>>
> print { $fh } data;

better not.

>Which is the documented alternative, and looks (almost) as good as the
>common use of your example.

That's still indirect object syntax, and for print (and presumably
other builtins) it's still special cased to compile to the print
opcode, not an actual method call

I think we have to especially allow new, print, DESTRY
and other cases which I cannot remember yet.
This will needs some tests. So that 99% of the code passes without
error.

The rest can be simply make it as default strictness.
use strict would add the indirect method check.
no strict 'indirect_method' would allow it.
--
Reini

Thu, Jul 10, 2008 at 02:47:14PM +0000, Ed Avis wrote:

If indirect object syntax really is bad then a warning or error needs to be
generated in the default case, because the people who currently don't read p5p
or PBP to find out they shouldn't use this syntax are the same people who won'
find out about some extra new flag.

I strongly disagree.

99% of the Perl programmers don't care what's considered to be "proper
coding" this week. They just want to solve their problems - and they
want their code to remain working if perl gets upgraded.

Introducing warnings for common code constructs that 999999 times out
of a 1000000 don't cause a problem at all (and where it does form a
problem, it's a repeatable problem, unlikely to depend on runtime values,
and hence, if the code works today, it will so tomorrow) is counterproductive
for the fast majority of the coders.



Abigail

Mon, Jul 14, 2008 at 01:34:48PM +0000, Ed Avis wrote:
Randal L. Schwartz <merlyn <atstonehenge.comwrites:
>>(I don't think it would be any great loss to require that constructors be named
>>'new',

>I do. I think it's better to name a constructor something that makes sense.

Fair enough, call the constructor what you wish, but only 'new' would be allowed
the special indirect object syntax (along with print and other builtins).
That's what I am suggesting.


Perl already has a named constructor. And that name is "bless".



Abigail

Jul 14, 2008, at 10:10 AM, Ed Avis wrote:

>Perl already has a named constructor. And that name is "bless".
>
Just to clarify, the assumptions I am starting from are:
>
- any fix made should not break (too much) existing code,

- but there are not so many cases of using indirect object syntax
for other things.



Ed,

Many (ok, a few) of us regularly use indirect object syntax as part of
our toolkit for bending Perl's syntax into domain specific languages.
If you're going to whack out indirect object syntax, you'll break an
awful lot of backward compatibility in places you wouldn't expect it.
Removing it isn't a bugfix so much as enforcing a style preference on
the community, which feels rather un-Perlish.

Creating a Perl::Critic policy which enforces this preference seems
like it would be a good way to ensure that indirect object syntax
doesn't crop up where it's not wanted without removing the rope that
some of us rely on.

Best,
Jesse

Jesse Vincent wrote:
Creating a Perl::Critic policy which enforces this preference seems like
it would be a good way to ensure that indirect object syntax doesn't
crop up where it's not wanted without removing the rope that some of us
rely on.

And just how is P::C supposed to detect this? Indirect object syntax is really, really hard to guess statically. A more likely place to attempt this would be B::Lint.

Monday 14 July 2008 07:57:39 Jesse Vincent wrote:

Many (ok, a few) of us regularly use indirect object syntax as part of
our toolkit for bending Perl's syntax into domain specific languages.

Sure, but you are in a state of sin and, if there is any justice in the world,
will someday have to maintain that code.

I'd rather write a parser, and you know how I feel about writing parsers.

-- c