Trait aliasing syntax suggestions View as Markdown

[snip...]

class A
{
trait foo;
}

class B
{
trait foo {unset bing, bar as bing};
trait bar;
}
?>

[snip...]

As long as we're discussing syntax - I rather like
class A
{
attach foo;
}

class B
{
attach foo {hide bing, bar as bing};
attach bar;
}

but that's just my opinion into the "how to do the syntax" discussion

I do like the "foo as bar" style aliasing, it will really make sense as
namespaces follow the same convention, but I think hide is more
appropriate than unset

As for attach keyword, well it's short and descriptive, you are
attaching new functionality to the class. I think that reusing trait
both as the way to put the trait in the class and to declare the trait
will confuse people.

My $0.02

Thanks,
Elizabeth Smith

Simply re-using "trait" instead of "use" is a more self-documenting
solution. I found it slightly confusing to see "use" when that is a
namespace-specific token currently. This is also in keeping with the
way functions are defined in interfaces vs. implementation, but in
reverse (for traits, brackets are used for declaration, semi-colon
used
for instantiation).

I like "trait" instead of "use" or any of the other proposals as well

Obviously, using "unset" is more similar to current PHP ideas on how
to
remove something, and the "as" syntax is also very PHP-ish, these will
be far more self-documenting than the proposed syntaxes I've read
thus far.

Unset seems to send the wrong message again. "hide" might be better?
As I said before "as" for aliasing is a good choice, or "alias" to
make it even clearer.

@Stefan: are you keeping track of all the different syntax proposals?

regards,
Lukas

Gregory Beaver wrote:

Here is a slightly clearer syntax for trait instantiation and for
aliasing/removing method names from traits:

<?php
trait foo

...

class B
{
trait foo {unset bing, bar as bing};
trait bar;
}

I like the approach to reuse identifiers (trait both in declaration and
use, clearly links the two) and unset/as (avoids new keywords).

Some more thoughts:

• I've seen Stefan Marr's remarks about aliasing != renaming but the
  only explanation I could find in the thread was about user perception
  (along the line of "... would expect all uses of the function to be
  renamed ..."). I don't think aliasing really helps here. I can see two
  use cases for aliasing: 1) An interface uses a different name than the
  trait implements. Not sure that's a software design problem trait should
  try to solve. 2) There is a clash with an existing function in the
  class. Then one would have to both alias and exclude the trait function
  name anyway (which is the same as renaming) PLUS you'd have the problem
  of trait classes calling the 'wrong' functions again. Maybe someone can
  shed light on why aliasing is preferable to renaming after all.
• I think the whole 'how to avoid clashes' discussion is missing one
  important point: Being able to override functions defined in a trait is
  a feature, not a bug. It's the same as with inheritance, i.e. if I
  override functions I can enhance but also break existing code. IMHO
  Traits should be a simple mechanism giving the developer the freedom to
  do the wrong thing ;-) Or more seriously: If you want to have
  encapsulated functionality used in multiple places I'd use delegates a
  la foo_traitemu::bar().
• The exclusion model is missing a way to include only specific
  functions. To me this seems as useful as being able to exclude functions.

So my favourite solution (apart from allowing include in class
definitions ;-)) would be
trait foo { ... }
...
class B
{
trait foo; # All functions from foo
trait bar(a); # Only function a from bar
trait qux(not b); # Everythign but function b
trait quux(c as d); # Include c but rename it to d
trait quuux(not b, c as d); # Combination of the above
}

Note: The inclusion of specific functions acts as if a "not *" (while *
doesn't really need to be implemented neither for inclusion nor
exclusion IMHO) was given first.

Another detail: The implementation of the parser changes should still
allow a class or function called "trait", i.e. "trait" should only be a
keyword at specific positions in the source to avoid unneccesary BC
breaks. The current patch has this BC problem.

• Chris

Hi,

what's about sample below?

<?php
class foo
{
public $aabb;
const bbaa = 'abba';
static public $baba;
function bar(){}
function bing(){}
}
class bar
{
const baab = foo::bbaa;
function bar(){}
}

class A
{
trait foo;
}

class B
{
trait foo {unset bing, bar as bing, unset $aabb, unset bbaa};
trait bar;
}
?>

in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?

just my two cents.
-j

"Gregory Beaver" greg@chiaraquartet.net wrote in message
news:47BD207C.2080905@chiaraquartet.net...

Hi,

Here is a slightly clearer syntax for trait instantiation and for
aliasing/removing method names from traits:

<?php
trait foo
{
function bar(){}
function bing(){}
}

trait bar
{
function bar(){}
}

class A
{
trait foo;
}

class B
{
trait foo {unset bing, bar as bing};
trait bar;
}
?>

Simply re-using "trait" instead of "use" is a more self-documenting
solution. I found it slightly confusing to see "use" when that is a
namespace-specific token currently. This is also in keeping with the
way functions are defined in interfaces vs. implementation, but in
reverse (for traits, brackets are used for declaration, semi-colon used
for instantiation).

Obviously, using "unset" is more similar to current PHP ideas on how to
remove something, and the "as" syntax is also very PHP-ish, these will
be far more self-documenting than the proposed syntaxes I've read thus
far.

Greg