[Fwd: Re: Renaming namespaces to packages]

PHP has namespaced package support.

Yep, that's what I was talking about. "We have namespaces but we call it
packages because Java does". Eek.

Take a look at this URL and tell me which one PHP does look like:
http://kaistizen.net/Project/CSharpJava/csharp_java.htm#NamespaceVsPackage

Wikipedia also define the term MVC. But alas, that is a conceptual
definition, not blueprints for implementation.

Who cares about the implementation? It's still MVC. So let's implement
MVC and call it "distributed enterprise messaging" and then let's spend
next 2 years explaining that it was really MVC that we meant.

namespaces and packages. But the general taste this will leave in
peoples mouthes is package, even if it is a Grapple.

I am still waiting to know what is package? I know what is namespace -
and I for everybody that doesn't know I can explain it in 2 minutes with
one hand tied behind my back. But what is "package"?

From Portuguese Brazilian Wikipedia: http://pt.wikipedia.org/wiki/Package
Translated to you....

One package is a group of classes and interfaces related.

In computers' area, package is a general purpose mechanism to organize
elements in groups. For example, a package java.io which holds all the
classes, in Java programming language, that handles with data
input/output.

Advantages: Easy to find and use the classes; Prevent conflicts in
respect to names (MY note: literal translation); access control;

The programmers must group in packages the classes and interfaces
correlated; The classes and platforms that make part of JAVA platform
are members of various packages. To create a package, you can only put
an interface and one class inside a package.

current implementation doesn't have braces; this (consequently) adds a

Ouch, not braces again. What is it with braces that you need them so
badly? Many languages aren't using the things ever, isn't it a proof
that there's life outside braces? ;)

Braces should only be used if you try to follow the scope idea I
already mentioned. But this is part of namespace paradigm.

library "packages". Point in case is how the ZF has used a
pesudo-namespace-ing class name to accomplish the very same thing.

ZF is using Very_Very_Long_And_Very_Irritating_Class_Names because
there's no choice to do otherwise. That's why we wrote namespaces - to
provide this choice.

If you are creating this patch only to simplify this, I recommend you
to keep it as PHP is currently and just add namespace/package support
with a serious implementation.

+1 on package, it makes the most sense regardless of the marketing draw
of "namespace" support.

Please re-read my mail on perception. "Marketing" here is just a way to
say "perception" so it sounds bad to some people for some reason.

All you told until now in favor of namespaces are marketing related.
Just read your previous messages.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Best regards,

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil

Stanislav Malyshev wrote:

Wikipedia also define the term MVC. But alas, that is a conceptual
definition, not blueprints for implementation.

Who cares about the implementation? It's still MVC. So let's implement
MVC and call it "distributed enterprise messaging" and then let's spend
next 2 years explaining that it was really MVC that we meant.

My point is simply that there is a different between the concept and
someones interpretation of the concept that influences an actual
implementation. MVC, although overly used in these web 2.1-rc4 days, is
not a product, or even an implementation.. Its a pattern for development
and a concept. ZF-MVC is an implementation of this pattern, as is
Symfony, as is RoR, as is Django.

I use the concept of Namespaces to build a more OO friendly session
object for Zend_Session. Which is why we have a class called
Zend_Session_Namespace. Point being, its an implementation of the
namespace concept within an implementation of a component in the Zend
Framework.

namespaces and packages. But the general taste this will leave in
peoples mouthes is package, even if it is a Grapple.

I am still waiting to know what is package? I know what is namespace -
and I for everybody that doesn't know I can explain it in 2 minutes with
one hand tied behind my back. But what is "package"?

PACKAGES ARE a namespace implementation with file/directory/and or other
filesystem restrictions.

I would go out on a limb and say that if you surveyed a large majority
of languages and developers, that statement above would fit most peoples
perception of "what a package is".

current implementation doesn't have braces; this (consequently) adds a

Ouch, not braces again. What is it with braces that you need them so
badly? Many languages aren't using the things ever, isn't it a proof
that there's life outside braces? ;)

Its not a point of needing them so badly. The point is what the lack of
braces implies within the language itself. Instead of namespace scope
ending at a brace, its now ending at the end OF A FILE; hence
introducing a FILESYSTEM restriction.

Questions: can I run an interactive php shell and define a few
namespaces and classes to use in a runtime environment? Say, using,
PHP_Shell in pear?

Can I have more than one namespace in a single file?

library "packages". Point in case is how the ZF has used a
pesudo-namespace-ing class name to accomplish the very same thing.

ZF is using Very_Very_Long_And_Very_Irritating_Class_Names because
there's no choice to do otherwise. That's why we wrote namespaces - to
provide this choice.

True, but we are also talking about library components that are
regulated by some coding standards, specifically, the one class per file
requirement. This itself is not a PHP thing, its a ZF-Coding Standards
thing. Using package implies a "one namespaced package per file rule"
whereas the simple term of "namespace" does not (at least to me).

+1 on package, it makes the most sense regardless of the marketing
draw of "namespace" support.

Please re-read my mail on perception. "Marketing" here is just a way to
say "perception" so it sounds bad to some people for some reason.

Well, you talked about sending out the press release about "PHP has
namespace support!".. and that is pure marketing ;)

But I agree with you in that the long term goal is about developer
perception, and thats why its important to have this decided.

-ralph

current implementation doesn't have braces; this (consequently) adds a

Ouch, not braces again. What is it with braces that you need them so
badly? Many languages aren't using the things ever, isn't it a proof
that there's life outside braces? ;)

Well.. My guess is that If current implementation had braces all this
namespace/package
thing wouldn't be even discussed now. Everyone would agree that it's
namespace thing
even if one must put all file contents inside braces for parser to be happy.

However without braces current implementation looks like nothing else
in PHP. This gives
people a space to improvise and/or pushes to look for similarities of
syntax in other
languages and it seems that the closest match is Java with its
packages even though the functionality is different.

I don't want to start braces discussion again but may suggest consider
adding them?
Pros:

• It would end this discussion
• It would be good for FC. If there would be decided to allow more
  then one namespace
  per file in the future.
• Syntax would be more consistent with existing constructs in the language
  (classes/functions/etc)

To sum up I think we have namespaces functionality with syntax similar
to Java packages.
Now the question is do we want developers to:

• use namespaces anr/or mimic packages functionality with "namespace" if they
  want to (+1 for namespace)
  OR
• use "package" the way it shouldn't be to mimic simple namespaces if they don't
  like/want/need packages (+1 for package)

Regards,
Giedrius

Stanislav Malyshev schrieb:

So for you packages == Java packages. Great, since PHP does not have
Java packages, problem solved, it's not packages.

You asked for a specification of packages in a programming language.
I just pointed you to the specification of packages in Java.

That's all :)

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Java just happens to be the programming language that I associate the
most with the programming language feature in question.

So for you packages == Java packages. Great, since PHP does not have
Java packages, problem solved, it's not packages.

So for you namespaces == C namespaces. Great, since PHP does not have
C packages, problem solved, it's not namespaces.

;-)

Tijnema

Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info

Read the purpose of both, which restrictions/limitations both have,
how are they defined, how are they used, etc and you'll see if the
current implementation is more like 'namespace' or 'package'. It's not
related to package Java, namespace C, def, zendspace of whatever.

That's what I am trying to explain for a week now and still failing.
Namespace as a concept is not the same as implementation of namespaces
in C++ or Java. Packages as a concept is not the same as implementation
of packages in Java, Perl, C or PHP. PHP is neither C++ not Java.
Choosing which language to mimic - Java or C++ - is not the right way to
think about the problem. PHP is separate language, not C++ or Java. Just
because C++ has + and PHP has + doesn't mean PHP should have operator
overloading. Just because PHP has multi-component names and Java has
multi-component names doesn't mean namespace definition operator should
be the same keyword. That's what I'm trying to explain - the choice is
not "should we be like C++ or like Java". We may end up being like it -
or not, but it is not the choice we have.

That's why I purposed the unique name. Also it follows the Gregory not
so likely email.

You can use zendspace. (Gregory) If you want me to get Johannes patch
and convert it to zendspace, just tell me.

• Allow nested definitions namespace N1 { namespace SubN1 { ... }
  namespace Sub2N1 { ... } }

That most probably won't happen ever. If you want to know why, look up
the nested class saga. In short - too much trouble to implement
consistently, too bad runtime performance (unlimited lookup depth at
runtime).

That's what I imagine it happens, otherwise that was no reason to not
allow more than one namespace/package per file.

not in packages). You tell me 'namespace' are unique. I agree, but
3rdparty libraries using the name namespace alias will still mess the
entire application. So let's follow bjori (IRC) idea and create the
"filescope"!

I'm afraid I don't understand - what would filescope do?

The reason to something like that is when you do:

import Foo::Bar as MyBar;

$c = new MyBar::NestedClass();

This can still cause a conflict.
Let me try to illustrate with a real world example (but hypotetical).
I use Zend Framework and at the same time ADOdb. Both has its
namespaces/packages:

namespace/package/zendspace/whatever Zend::DB;
class Connection { ... }

namespace ADO::DB;
class Connection { ... }

Internally in the Zend framework (in a class definition, for exmaple),
it can use:

package Zend::Foo;

import Zend::DB as DB;
$c = new DB::Connection();

And internally in the ADO package:

namespace ADO::Bar;

import ADO::DB as DB;
$c = new DB::Connection();

What will happen in this situation?

The idea of file scope works like this:

If it's internal to a package/namespace, that alias is restricted to
THAT package/namespace. If it's not internal to any space, it's global
and can be used as expected.
I think my idea is better explained with an example:

File: ORM/Client.php
<?php

namespace ORM

// Assign namespace in localscope (file scope, based on PHP implementation)
import System; // Contains Console class which controle I/O, like C#

class Client {
function __construct() {
Console::println( "Client created!" );
}
}

?>

File: index.php
<?php

// Console directly is unreachable, you must do this:
System::Console::println( "Unreachable" );

// Or import System again to allow it in global scope
import System;

Console::println( "Reachable now!" );

?>

Do you understand the idea now? I can try to explain differently if needed.

Regards,

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil

Hello Stanislav,

Thursday, August 16, 2007, 7:13:45 PM, you wrote:

Read the purpose of both, which restrictions/limitations both have,
how are they defined, how are they used, etc and you'll see if the
current implementation is more like 'namespace' or 'package'. It's not
related to package Java, namespace C, def, zendspace of whatever.

That's what I am trying to explain for a week now and still failing.

Wrong!!!! You started to defend the current state with a non existing JS
feature. And then you found a wiki page. Wow now wiki is the
all-knowing-trash-dump?

Namespace as a concept is not the same as implementation of namespaces
in C++ or Java. Packages as a concept is not the same as implementation
of packages in Java, Perl, C or PHP. PHP is neither C++ not Java.
Choosing which language to mimic - Java or C++ - is not the right way to
think about the problem. PHP is separate language, not C++ or Java. Just
because C++ has + and PHP has + doesn't mean PHP should have operator
overloading. Just because PHP has multi-component names and Java has
multi-component names doesn't mean namespace definition operator should
be the same keyword. That's what I'm trying to explain - the choice is
not "should we be like C++ or like Java". We may end up being like it -
or not, but it is not the choice we have.

So going with existing expectation is good or bad?

And then if there are two things, The concept and the implementation.
Wouldn't it make sense to not use the marking relevant one in the
implementation and instead use package in the implementation as that is what
we are implementing. At least when looking at the code and its behavior. And
then use the damn word 'namespaces' in PR material? Oh and don't forget your
namespace wiki matches both concepts. The concept of namespace in existing
languages (with nesting and stuff) and the package stuff which is limited to
one per file.

Best regards,
Marcus