UML, ZF Coding Standard differences in Zend_Pdf

[André Hoffmann]

Hi,

I'm currently working on an UML export/import tool for PHP 5 as there is absolutely no fully functional open source tool available at the moment.

After reading the ZF roadmap I wasn't sure whether or not this is something that would make sense in the Zend Framework. If so I'd be willing to contribute, since I guess that I'm not the only one who's in need of a tool like this.
What do you think?

While reverse-engineering the ZF for testing purposes I came across some major Coding Standard differences in the Zend Framework concerning the classes in Zend/Pdf/Resource:
For example Zend_Pdf_Image is not(as you would guess by the name) located in Zend/Pdf/Image.php, but in Zend/Pdf/Resource/Image.php.
I couldn't double-check this with the Coding Standard though as the wiki seems to be down(502 Proxy Error).

I'm aware that __autoload is not used in the Zend Framework and therefore this is not such a big deal, but since I'm a fan of the "class name represents the location"-model I'd like to mention it at least(given the almost final stage of the ZF).

--
best regards,
André Hoffmann

[Lars Strojny-2]

Hi,

Am Montag, den 19.02.2007, 14:01 +0100 schrieb André Hoffmann:
[...]

> While reverse-engineering the ZF for testing purposes I came across
> some major Coding Standard differences in the Zend Framework
> concerning the classes in Zend/Pdf/Resource:
> For example Zend_Pdf_Image is not(as you would guess by the name)
> located in Zend/Pdf/Image.php, but in Zend/Pdf/Resource/Image.php.
> I couldn't double-check this with the Coding Standard though as the
> wiki seems to be down(502 Proxy Error).
>
> I'm aware that __autoload is not used in the Zend Framework and
> therefore this is not such a big deal, but since I'm a fan of the
> "class name represents the location"-model I'd like to mention it at
> least(given the almost final stage of the ZF).

__autoload() is of course used in ZF. A lot of tutorials suggest to
either define function __autoload($className)
{ Zend::loadClass($className) } or to do
spl_register_autoload(array("Zend", "loadClass")). Not just as a matter
of this fact it is definitely a bug and should be fixed. Thanks for your
hint.

Greetings, Lars
--
      "Kriterium des Wahren ist nicht seine unmittelbare
          Kommunizierbarkeit an jedermann"
         -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik«

name: Lars H. Strojny      web: http://strojny.net 
street: Engelsstraße 23    blog: http://usrportage.de
city: D-51103 Köln         mail/jabber: [hidden email]
f-print: 1FD5 D8EE D996 8E3E 1417  328A 240F 17EB 0263 AC07

[Nico Edtinger-2]

[19.02.2007 14:24] Lars Strojny wrote:
> __autoload() is of course used in ZF. A lot of tutorials suggest to
> either define function __autoload($className)
> { Zend::loadClass($className) } or to do
> spl_register_autoload(array("Zend", "loadClass")).

Sorry to be pedantic. But __autoload() is not used by the ZF. ZF uses  
require_once. But you may use the ZF with __autoload(). That's IMO an  
important difference.

nico

[Alexander Veremyev]

Hi all,

It's not a bug. It's a feature :)


Zend_Pdf_Image is not intended to be used without Zend_Pdf class.

Zend/Pdf/Resource/Image.php file is loaded by require_once() call in
Zend/Pdf.php file.

So there are no problem for classes autoloading.


The reason for such coding standards breaking is the fact that
Zend_Pdf_Resource class is "implementation details" which should not be
used (directly or through descendant classes) in userland. So it's
hidden from end users to simplify API.
That's described in Zend_Pdf_Image class comments:
---------------
Class is named not in accordance to the name convention.
It's "end-user" class, but its ancestor is not.
Thus part of the common class name is removed.
---------------


 From the other side there are no any other reason to make this coding
standards break.


With best regards,
    Alexander Veremyev.


Lars Strojny wrote:

> Hi,
>
> Am Montag, den 19.02.2007, 14:01 +0100 schrieb André Hoffmann:
> [...]
>> While reverse-engineering the ZF for testing purposes I came across
>> some major Coding Standard differences in the Zend Framework
>> concerning the classes in Zend/Pdf/Resource:
>> For example Zend_Pdf_Image is not(as you would guess by the name)
>> located in Zend/Pdf/Image.php, but in Zend/Pdf/Resource/Image.php.
>> I couldn't double-check this with the Coding Standard though as the
>> wiki seems to be down(502 Proxy Error).
>>
>> I'm aware that __autoload is not used in the Zend Framework and
>> therefore this is not such a big deal, but since I'm a fan of the
>> "class name represents the location"-model I'd like to mention it at
>> least(given the almost final stage of the ZF).
>
> __autoload() is of course used in ZF. A lot of tutorials suggest to
> either define function __autoload($className)
> { Zend::loadClass($className) } or to do
> spl_register_autoload(array("Zend", "loadClass")). Not just as a matter
> of this fact it is definitely a bug and should be fixed. Thanks for your
> hint.
>
> Greetings, Lars

[Kevin McArthur-2]

I'm reworking Zend_Pdf_Image anyway, so it will be totally different pre
1.0.

This upgrade is logged as ZF-11 and the status is approximately 50%
complete.

Kevin
----- Original Message -----
From: "Alexander Veremyev" <[hidden email]>
To: "Lars Strojny" <[hidden email]>
Cc: <[hidden email]>; "André Hoffmann"
<[hidden email]>
Sent: Monday, February 19, 2007 11:46 AM
Subject: Re: [fw-general] UML, ZF Coding Standard differences in Zend_Pdf

> Hi all,
>
> It's not a bug. It's a feature :)
>
>
> Zend_Pdf_Image is not intended to be used without Zend_Pdf class.
>
> Zend/Pdf/Resource/Image.php file is loaded by require_once() call in
> Zend/Pdf.php file.
>
> So there are no problem for classes autoloading.
>
>
> The reason for such coding standards breaking is the fact that
> Zend_Pdf_Resource class is "implementation details" which should not be
> used (directly or through descendant classes) in userland. So it's hidden
> from end users to simplify API.
> That's described in Zend_Pdf_Image class comments:
> ---------------
> Class is named not in accordance to the name convention.
> It's "end-user" class, but its ancestor is not.
> Thus part of the common class name is removed.
> ---------------
>
>
> From the other side there are no any other reason to make this coding
> standards break.
>
>
> With best regards,
>    Alexander Veremyev.
>
>
> Lars Strojny wrote:
>> Hi,
>>
>> Am Montag, den 19.02.2007, 14:01 +0100 schrieb André Hoffmann:
>> [...]
>>> While reverse-engineering the ZF for testing purposes I came across
>>> some major Coding Standard differences in the Zend Framework
>>> concerning the classes in Zend/Pdf/Resource:
>>> For example Zend_Pdf_Image is not(as you would guess by the name)
>>> located in Zend/Pdf/Image.php, but in Zend/Pdf/Resource/Image.php. I
>>> couldn't double-check this with the Coding Standard though as the
>>> wiki seems to be down(502 Proxy Error).
>>>
>>> I'm aware that __autoload is not used in the Zend Framework and
>>> therefore this is not such a big deal, but since I'm a fan of the
>>> "class name represents the location"-model I'd like to mention it at
>>> least(given the almost final stage of the ZF).
>>
>> __autoload() is of course used in ZF. A lot of tutorials suggest to
>> either define function __autoload($className)
>> { Zend::loadClass($className) } or to do
>> spl_register_autoload(array("Zend", "loadClass")). Not just as a matter
>> of this fact it is definitely a bug and should be fixed. Thanks for your
>> hint.
>>
>> Greetings, Lars
>

[Lars Strojny-2]

Hi,

Am Montag, den 19.02.2007, 21:46 +0300 schrieb Alexander Veremyev:
> Hi all,
>
> It's not a bug. It's a feature :)

It's not :-)

> Zend_Pdf_Image is not intended to be used without Zend_Pdf class.
>
> Zend/Pdf/Resource/Image.php file is loaded by require_once() call in
> Zend/Pdf.php file.
>
> So there are no problem for classes autoloading.

That's not the thing. It has something to do with conventions.
Conventions suck when there are exceptions. There are a lot of classes
in the Zend Framework which are not indended for the plain usage of a
common user. The normal concept for hiding a class is to just not
document the class. I would like to ask you to move or rename the class,
it does not make any sense. Or at least, until now it does not make any
sense.

Nice Greetings, Lars Strojny
--
      "Kriterium des Wahren ist nicht seine unmittelbare
          Kommunizierbarkeit an jedermann"
         -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik«

name: Lars H. Strojny      web: http://strojny.net 
street: Engelsstraße 23    blog: http://usrportage.de
city: D-51103 Köln         mail/jabber: [hidden email]
f-print: 1FD5 D8EE D996 8E3E 1417  328A 240F 17EB 0263 AC07

[Matthew Ratzloff]

I believe he uses this method to shorten the class name.

Zend_Pdf_Resource_Image_Jpeg => Zend_Pdf_Image_Jpeg

I would argue in favor of convention over a few less keystrokes.  It's a
longer name, but that's one of the downsides of using a language that has no
namespace support.  :-)

import Zend.Pdf.Resource.Image.Jpeg as PdfJpeg;

$jpeg = new PdfJpeg('some/image.jpg');

-Matt

----- Original Message -----
From: "Lars Strojny" <[hidden email]>
To: <[hidden email]>
Sent: Monday, February 19, 2007 12:51 PM
Subject: Re: [fw-general] UML, ZF Coding Standard differences in Zend_Pdf

> Zend_Pdf_Image is not intended to be used without Zend_Pdf class.
>
> Zend/Pdf/Resource/Image.php file is loaded by require_once() call in
> Zend/Pdf.php file.
>
> So there are no problem for classes autoloading.

That's not the thing. It has something to do with conventions.
Conventions suck when there are exceptions. There are a lot of classes
in the Zend Framework which are not indended for the plain usage of a
common user. The normal concept for hiding a class is to just not
document the class. I would like to ask you to move or rename the class,
it does not make any sense. Or at least, until now it does not make any
sense.