bug or feature? (OO design/languages)

[www.douglassdavis.com]

All three of the following classes give "compile-time" errors. It
hinders me from doing what I want to do... And it seems there is no way
around it. But, are each of these cases examples of how the language
should behave? Are any of the examples a case of PHP being
"incorrect? "


class MyClass
{
static $x = 2;
static $y = self::$x; // error
}

class MyClass2
{
var $x = 2;
static $y = $x; // error
}


class MyClass3
{
const a = array(1,2); // error
}

--

http://www.douglassdavis.com/

[raf]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com wrote:[color=blue]
> All three of the following classes give "compile-time" errors. It
> hinders me from doing what I want to do... And it seems there is no way
> around it. But, are each of these cases examples of how the language
> should behave? Are any of the examples a case of PHP being
> "incorrect? "[/color]

I don't know PHP, but I believe these are bugs in your code:

[color=blue]
> class MyClass
> {
> static $x = 2;
> static $y = self::$x; // error
> }[/color]

there is no instantiation of the class--there is no "self" object.
Did you mean "static $y = $x"?
[color=blue]
> class MyClass2
> {
> var $x = 2;
> static $y = $x; // error
> }[/color]

In this case, since no object was created, there is no $x to assign into
$y.
[color=blue]
> class MyClass3
> {
> const a = array(1,2); // error
> }[/color]

I defer this to someone who knows PHP, but if its semantics are
comparable to Java and C#, does "array(1,2) " actually create an instance
of an array? Based on the pattern of the errors above, I'd suggest you
review the concepts of object instantiation and class/instance member
variables.

raf

[www.douglassdavis.com]

Re: bug or feature? (OO design/languages)


raf wrote:[color=blue]
> www.douglassdavis.com wrote:[color=green]
> > All three of the following classes give "compile-time" errors. It
> > hinders me from doing what I want to do... And it seems there is no way
> > around it. But, are each of these cases examples of how the language
> > should behave? Are any of the examples a case of PHP being
> > "incorrect? "[/color]
>
> I don't know PHP, but I believe these are bugs in your code:
>
>[color=green]
> > class MyClass
> > {
> > static $x = 2;
> > static $y = self::$x; // error
> > }[/color]
>
> there is no instantiation of the class--there is no "self" object.
> Did you mean "static $y = $x"?[/color]

self:: isn't $this-> self:: just refers to the current class, just
like putting the class name there. In PHP, you always have to prefix a
class variable with something, even if you are writing code in that
class.

[color=blue][color=green]
> > class MyClass2
> > {
> > var $x = 2;
> > static $y = $x; // error
> > }[/color]
>
> In this case, since no object was created, there is no $x to assign into
> $y.
>[/color]

yes... this one doesn't make sense.
[color=blue][color=green]
> > class MyClass3
> > {
> > const a = array(1,2); // error
> > }[/color]
>
> I defer this to someone who knows PHP, but if its semantics are
> comparable to Java and C#, does "array(1,2) " actually create an instance
> of an array? Based on the pattern of the errors above, I'd suggest you
> review the concepts of object instantiation and class/instance member
> variables.[/color]

yes array creates an instance of array.


to the PHP folks out there:

My delima is this... let's say you wanted to do something like this in
a class, and you needed all 3 of these vars to be defined.

class MyClass4
{
var $one = array(1,2);
var $two = array(3,4);
var $three= array($one, $two); // a two dimensional array.
// ... more code below
}

But you knew that these would always remain the same, and there was no
need for putting them in every class. Meaning, if they are not static,
it's just a waste of space.

Also, there are no static initializer blocks like java.

Is there a correct way to define this in the class this without wasting
space?

[Phlip]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com wrote:
[color=blue]
> PHP[/color]

Is it too late to switch to Ruby?

That's not a joke; it's an excellent language that will lead to very elegant
solutions here.
[color=blue]
> My delima is this... let's say you wanted to do something like this in
> a class, and you needed all 3 of these vars to be defined.
>
> class MyClass4
> {
> var $one = array(1,2);
> var $two = array(3,4);
> var $three= array($one, $two); // a two dimensional array.
> // ... more code below
> }
>
> But you knew that these would always remain the same, and there was no
> need for putting them in every class. Meaning, if they are not static,
> it's just a waste of space.[/color]

Premature optimization is the root of all evil. In this case, if you need an
object, even as a compilable comment, create an object.

Put another way, it's easier to make clean code fast than make fast code
clean. Clean code is easy to read and understand. Create an object that
duplicates its instances of these heavy members. Then get your program to
work, and then think about _explicitely_ replacing the heavy members with
references to shared single instances of their data.
[color=blue]
> Also, there are no static initializer blocks like java.[/color]

Write them yourself. In Ruby, they would be...

@@one ||= [1,2]

one is a class variable, and if it's not assigned yet then create an array
and plug it in.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Dikkie Dik]

Re: bug or feature? (OO design/languages)

I think you get the compile time errors because the class properties can
be initialized with a constant expression only. Calling a function or
another variable is not seen as a constant expression, even if the
result is a constant.
This is a language thing, so I think you will have to live with it.

What you can do is creating some "root" instance of your class and set
the properties in the constructor. This also has the advantage of a more
testable object model.

Best regards

www.douglassdavis.com wrote:[color=blue]
> raf wrote:
>[color=green]
>>www.douglassdavis.com wrote:
>>[color=darkred]
>>>All three of the following classes give "compile-time" errors. It
>>>hinders me from doing what I want to do... And it seems there is no way
>>>around it. But, are each of these cases examples of how the language
>>>should behave? Are any of the examples a case of PHP being
>>>"incorrect ?"[/color]
>>
>>I don't know PHP, but I believe these are bugs in your code:
>>
>>
>>[color=darkred]
>>>class MyClass
>>>{
>>> static $x = 2;
>>> static $y = self::$x; // error
>>>}[/color]
>>
>>there is no instantiation of the class--there is no "self" object.
>>Did you mean "static $y = $x"?[/color]
>
>
> self:: isn't $this-> self:: just refers to the current class, just
> like putting the class name there. In PHP, you always have to prefix a
> class variable with something, even if you are writing code in that
> class.
>
>
>[color=green][color=darkred]
>>>class MyClass2
>>>{
>>> var $x = 2;
>>> static $y = $x; // error
>>>}[/color]
>>
>>In this case, since no object was created, there is no $x to assign into
>> $y.
>>[/color]
>
>
> yes... this one doesn't make sense.
>
>[color=green][color=darkred]
>>>class MyClass3
>>>{
>>> const a = array(1,2); // error
>>>}[/color]
>>
>>I defer this to someone who knows PHP, but if its semantics are
>>comparable to Java and C#, does "array(1,2) " actually create an instance
>>of an array? Based on the pattern of the errors above, I'd suggest you
>>review the concepts of object instantiation and class/instance member
>>variables.[/color]
>
>
> yes array creates an instance of array.
>
>
> to the PHP folks out there:
>
> My delima is this... let's say you wanted to do something like this in
> a class, and you needed all 3 of these vars to be defined.
>
> class MyClass4
> {
> var $one = array(1,2);
> var $two = array(3,4);
> var $three= array($one, $two); // a two dimensional array.
> // ... more code below
> }
>
> But you knew that these would always remain the same, and there was no
> need for putting them in every class. Meaning, if they are not static,
> it's just a waste of space.
>
> Also, there are no static initializer blocks like java.
>
> Is there a correct way to define this in the class this without wasting
> space?
>[/color]

[Malcolm Dew-Jones]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com (doug@douglassd avis.com) wrote:

: static $y = self::$x; // error

I wonder if that should be $self::x;


--

This programmer available for rent.

[www.douglassdavis.com]

Re: bug or feature? (OO design/languages)


Phlip wrote:[color=blue]
> www.douglassdavis.com wrote:
>[color=green]
> > PHP[/color]
>
> Is it too late to switch to Ruby?
>
> That's not a joke; it's an excellent language that will lead to very elegant
> solutions here.[/color]

I'll check it out, but this kinda scared me:

Features of Ruby

* Ruby has simple syntax, partially inspired by Eiffel and Ada.

IMO, there's a reason why people aren't flocking to use Eiffel and
Ada... Although Ruby it should be interesting, so I'll take a look.

[raf]

Re: bug or feature? (OO design/languages)

[my feeble attempts to debug PHP code snipped][color=blue]
> My delima is this... let's say you wanted to do something like this in
> a class, and you needed all 3 of these vars to be defined.
>
> class MyClass4
> {
> var $one = array(1,2);
> var $two = array(3,4);
> var $three= array($one, $two); // a two dimensional array.
> // ... more code below
> }
>
> But you knew that these would always remain the same, and there was no
> need for putting them in every class. Meaning, if they are not static,
> it's just a waste of space.[/color]

First, your descriptive naming conventions don't help in understanding
the intent of your code.

Second, what do you mean "always remain the same?" Do you mean that
every single instance of MyClass4 shares the exact same single instance
of each of those arrays?

If so, might it be worth considering factoring out the array and using a
Singleton pattern for whatever they represent?

If not, rethink your design. And your naming conventions.'
[color=blue]
> Also, there are no static initializer blocks like java.[/color]

Makes me wonder why people flock to use PHP then ;-)

[color=blue]
> Is there a correct way to define this in the class this without wasting
> space?[/color]

See my suggestion above...

raf

[Phlip]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com wrote:
[color=blue]
> I'll check it out, but this kinda scared me:
>
> Features of Ruby
>
> * Ruby has simple syntax, partially inspired by Eiffel and Ada.
>
> IMO, there's a reason why people aren't flocking to use Eiffel and
> Ada... Although Ruby it should be interesting, so I'll take a look.[/color]

I don't know who wrote that. Ruby was invented to compete directly,
head-to-head, with both Perl and Smalltalk at the same time. That's an
incredible stretch, and Matz did it by bowing to Perl's kewtzey /regexp/
syntax, with magic $1 and $2 variables for the match results. Matz then
fixed this otherwise ridiculous system by making $ the prefix for global
variables _only_. That instantly makes $1 and $2 work, because they are
nothing but stereotypical global variables.

Ruby competes with Smalltalk by making everything an object, including
classes, and making all objects indefinitely extensible. Oh, and block
closures so you don't need zillions of lines of code to get trivial things
done. Block closures permit local variables to have the narrowest scope
possible over indefinite lifespans, enhancing encapsulation without the need
for excessive plumbing to route those variables into the called-back block
where they are ultimately used.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Janwillem Borleffs]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com wrote:[color=blue]
> class MyClass2
> {
> var $x = 2;
> static $y = $x; // error
> }
>[/color]

$x does not exist until instantiation, so you should assign $y in the
constructor:

class MyClass2 {
var $x = 2;
static $y;

function __construct() {
$this->y = $this->x;
}
}

The same principle applies to the previous MyClass code, where $this->x
should be replaced by self::$x.
[color=blue]
> class MyClass3
> {
> const a = array(1,2); // error
> }[/color]

From http://www.php.net/manual/en/language.constants.php:

"Only scalar data (boolean, integer, float and string) can be contained in
constants."


JW

[Janwillem Borleffs]

Re: bug or feature? (OO design/languages)

Janwillem Borleffs wrote:[color=blue]
> class MyClass2 {
> var $x = 2;
> static $y;
>
> function __construct() {
> $this->y = $this->x;
> }
> }
>[/color]

Bad example as $y is set as a normal class property instead of a static. In
general, statics should be assigned with hardcoded values if you want to
access them directly without creating an instance of the class first.


JW

[Adie]

Re: bug or feature? (OO design/languages)

Phlip wrote:
[color=blue]
> www.douglassdavis.com wrote:
>[color=green]
>> I'll check it out, but this kinda scared me:
>>
>> Features of Ruby
>>
>> * Ruby has simple syntax, partially inspired by Eiffel and Ada.
>>
>> IMO, there's a reason why people aren't flocking to use Eiffel and
>> Ada... Although Ruby it should be interesting, so I'll take a look.[/color]
>
> I don't know who wrote that. Ruby was invented to compete directly,
> head-to-head, with both Perl and Smalltalk at the same time. That's an
> incredible stretch, and Matz did it by bowing to Perl's kewtzey /regexp/
> syntax, with magic $1 and $2 variables for the match results. Matz then
> fixed this otherwise ridiculous system by making $ the prefix for global
> variables _only_. That instantly makes $1 and $2 work, because they are
> nothing but stereotypical global variables.
>
> Ruby competes with Smalltalk by making everything an object, including
> classes, and making all objects indefinitely extensible. Oh, and block
> closures so you don't need zillions of lines of code to get trivial things
> done. Block closures permit local variables to have the narrowest scope
> possible over indefinite lifespans, enhancing encapsulation without the need
> for excessive plumbing to route those variables into the called-back block
> where they are ultimately used.[/color]

And I guess C++ is not worth the effort.

[www.douglassdavis.com]

Re: bug or feature? (OO design/languages)


raf wrote:[color=blue]
>
> First, your descriptive naming conventions don't help in understanding
> the intent of your code.[/color]

the only intent was to demonstrate a language concept. :)
[color=blue]
> Second, what do you mean "always remain the same?" Do you mean that
> every single instance of MyClass4 shares the exact same single instance
> of each of those arrays?
>
> If so, might it be worth considering factoring out the array and using a
> Singleton pattern for whatever they represent?[/color]

sure.. that's an option. Since it's just a bunch of data that doesn't
change, I was wondering if i could use member variables to represent
them, rather than classes... But, good suggestion though.
[color=blue]
> If not, rethink your design. And your naming conventions.'[/color]

That was only an example :) The real code is too long.
[color=blue][color=green]
> > Also, there are no static initializer blocks like java.[/color]
>
> Makes me wonder why people flock to use PHP then ;-)[/color]

Because we actually like programming in PHP :)

[raf]

Re: bug or feature? (OO design/languages)

www.douglassdavis.com wrote:[color=blue]
> raf wrote:
>[color=green]
>>First, your descriptive naming conventions don't help in understanding
>>the intent of your code.[/color]
>
>
> the only intent was to demonstrate a language concept. :)[/color]

Unfortunately your fragment, though just a small demonstration, shows
the potential shortcoming of using code as a "design artifact"--it
showed me what you did, but gave me no insight in what your intent was.
did those arrays represent a game board and the classes represented
player controllers? Were they tables in a restaurant and the classes
represented bus boys? The PHP problem was one level of concern, but if
we had more insight into what you were trying to do it would make things
easier.

names matter.

raf
[color=blue]
> sure.. that's an option. Since it's just a bunch of data that doesn't
> change, I was wondering if i could use member variables to represent
> them, rather than classes... But, good suggestion though.[/color]

"bunch of data"? where the abstraction, man? "I've got a loverly bunch
of data... here they are, standing in a row"

What does the data represent?
[color=blue]
> That was only an example :) The real code is too long.[/color]

no need to post the entire codebase, but just two or three sentences
describing what the fragment represented and meaningful names... that
should be easy, no?
[color=blue][color=green]
>>Makes me wonder why people flock to use PHP then ;-)[/color]
>
>
> Because we actually like programming in PHP :)[/color]

Just like Eiffel and Ada programmers, I suppose.

raf

[www.douglassdavis.com]

Re: bug or feature? (OO design/languages)

raf wrote:
....[color=blue]
> represented bus boys? The PHP problem was one level of concern, but if
> we had more insight into what you were trying to do it would make things
> easier.
>
> names matter.
>
> raf
>[color=green]
> > sure.. that's an option. Since it's just a bunch of data that doesn't
> > change, I was wondering if i could use member variables to represent
> > them, rather than classes... But, good suggestion though.[/color]
>
> "bunch of data"? where the abstraction, man? "I've got a loverly bunch
> of data... here they are, standing in a row"[/color]

exactly.

And thanks for solving the problem, that you knew nothing about. :-|
[color=blue][color=green]
> > Because we actually like programming in PHP :)[/color]
>
> Just like Eiffel and Ada programmers, I suppose.[/color]

Ok, I'll give you Eiffel... Although many of the users are academic,
rather than real world. I remember I had to take a class on it. As
far as Ada goes, there's a significant number of people who program in
Ada because they -have- to.


Also, there is a difference between being "correct" and being
"practical. " ;-)