Re: [PHP-DEV] Re: Array syntax []

[Giedrius D]

On Jan 11, 2008 1:19 PM, Pierre [EMAIL PROTECTED] wrote:
 Hi,

 Guys, there is really no point to argue about aesthetic or taste. Make
 your point by using +1/-1 and that's it. As said, the trolls quota has
 been used already.


+1 FWIW :-)

--
Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Square brackets shortcut

[Giedrius D]

Hi,

On Jan 10, 2008 3:56 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
 So you reject scalar type hinting because it isn't type casting and
 can therefor confuses newbies - but scattering seemingly random
 brackets around your code (to safe 5 key strokes) is obvious to users?

 Noone would confuse this with named arguments?
 Why can't I do function foo([] $array) {} ?
Can you do function foo(array() $array) {} ?


 foo([]);
 $var = [];
 Is this really readable?
Looks readable to me ;-)

FWIW if it's going to be implemented I think (b) should be the choice
as it is more consistent with current syntax even though I like (a)
more.


 Are you really serious about this?

 -Hannes



 On Jan 10, 2008 11:19 AM, Marcus Boerger [EMAIL PROTECTED] wrote:
  Hello Ryusuke,
 
I like b) !
 
  marcus
 
 
  Thursday, January 10, 2008, 11:07:36 AM, you wrote:
 
   Hello, lists,
 
   I'm tired to type array() many times. And I want to
   declare arrays more easily. So I wrote the patch for
   zend_language_parser.y which enables to declare arrays
   with square brackets like some other languages.
 
   Stanislav,
   Sorry, I'm new in this list and I didn't know about past
   discussion. As Marcus says, I'd like to ask around again.
 
 
   There are three options:
 
a) Commit square bracket array shortcut patch
   keys and values are separated by colons.
   ( http://www.opendogs.org/pub/php-5.3dev-080109-sbar.patch )
   e.g.
   $a = [1, 2, 3];
   $b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
 
b) Commit square bracket array shortcut patch
   keys and values are separated by double arrows.
   ( http://www.opendogs.org/pub/php-5.3dev-080109-sbar2.patch )
   e.g.
   $a = [1, 2, 3];
   $b = ['foo' = 'orange', 'bar' = 'apple', 'baz' = 'lemon'];
 
c) Reject and keep using `array()'.
   e.g.
   $a = array(1, 2, 3);
   $b = array('foo' = 'orange', 'bar' = 'apple', 'baz' = 'lemon');
 
   These patches include the tests.
 
   Which do you like? I like (a) the best.
 
 
   Regards,
 
 
   2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
   Hello Stanislav,
  
 tha makesw three then already, how about we ask around again?
   Ryusuke, can you please start a new '[RFC] Square brackets shortcut' 
   thread
   to collect opinions and pass along the patch for that?
  
   I like the anonymous function patch too. It is clean and simple. Maybe 
   you
   want to start a second '[RFC] Anonymous functions' thread with that 
   patch.
  
   Can you also please add tests for both?
  
   marcus
  
   Wednesday, January 2, 2008, 7:51:06 PM, you wrote:
  
the square bracket array syntax patch for PHP 5.3,
  http://www.opendogs.org/pub/php-5.3dev-080101-sbar.patch
  
I remember we discussed that already and it was rejected then (even
though myself and Andi liked it) - did the people that objected then
change their minds?
  
  
  
   Best regards,
Marcus
  
  
 
 
   --
   /**
* Ryusuke SEKIYAMA
* [EMAIL PROTECTED]
*/
 
 
 
 
  Best regards,
   Marcus
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



Regards,
Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Type hinting misunderstood

[Giedrius D]

On Jan 6, 2008 5:55 PM, Sam Barrow [EMAIL PROTECTED] wrote:
 As I said, this patch is not intended for stuff like $_GET, $_POST,
 database data, etc. It is intended for internal functions to your
 application.

 function requireFile(string $file, bool $getOutput = false, array $args
 = array())
 {
 $obLevel = ob_get_level() ;

 ob_start() ;

 $return = require_once($file) ;

 if ($getOutput)
 {
 $return = ob_get_clean() ;
 }
 else
 {
 if ($_mod['base']['output']['strict'] and 
 ob_get_length()  0)
 {
 ::error::go('Output generated 
 in file ' . $file . '.') ;
 }

 ob_end_clean() ;
 }

 if ($obLevel !== ob_get_level())
 {
 ::error::go('Output buffering level mismatch 
 after inclusion of file
 ' . $file . '.') ;
 }

 return $return ;
 }

 This function will not be called using input data.

I have been watching type hinting for a while now and one thing I
don't understand: hows my object of class lets say FileName that
implements __toString() is wrong parameter for your requireFile()? Why
should I every time calling a function cast variables manually when it
can be perfectly done by PHP automatically?

Sorry for intrusion and thanks for your time.

Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: import/use last call

[Giedrius D]

Hi,

sorry if I missed something but is there any reason to not use keyword use?

IMHO allowing keywords in class, method, function, etc. names brings
more confusion then value.

On 10/23/07, Gregory Beaver [EMAIL PROTECTED] wrote:
 Stanislav Malyshev wrote:
  Hold off for a bit - I may have a simple solution that solves the
  problem for class names, method names and functions, have to code the
  patch tonight first to prove it works.
 
  OK, please send it as soon as you have it :)
 Hi,

 The attached patch is for PHP 5.3, if it is acceptable, I will port it
 to PHP 6, which is not difficult, although it does involve a lot of
 cut/pasting.

 The patch does these things:

 1) fixes an unrelated bug I found in implementation of LSB - static is
 not checked for in zend_do_import()/zend_do_namespace() and other places
 that we check for self and parent
 2) fixes a rather serious error in the fix for Bug #42859 - missing
 parens in zend_do_import()
 3) adds import and namespace as valid function/class names
 4) allows any string for method names, just as we allow any string for
 variable names
 5) fixes a bug in logic for $class-list where $class- list (note the
 whitespace between - and list) returns a T_LIST instead of T_STRING
 6) It allows import ::Classname as Blah which is currently a parse error
 7) class constants are unchanged - reserved words still error out.

 Note that the zend_compile.c fixes can all be committed directly as they
 are all bugfixes and not related to the import/namespace/reserved words fix.

 To implement this, I added several states to the lexer in order to
 return T_STRING whenever possible, which is after T_NEW, T_INTERFACE,
 T_CLASS, T_EXTENDS and in the T_IMPLEMENTS list.  In addition, after
 T_FUNCTION outside of a class, it returns T_STRING for import and
 namespace but no other reserved words.  After T_FUNCTION inside of a
 class (method declaration), it returns T_STRING for all possible
 strings.  After :: or - T_STRING is always returned.  Also, rather than
 take the approach LSB does with T_STATIC, I have the lexer initialize
 the string value of T_IMPORT and T_NAMESPACE so we can preserve case for
 autoloading needs.  The parser frees the unused char * when normal
 import/namespace declarations are called.

 In the parser, I use fully_qualified_class_name instead of
 namespace_name for both import syntaxes.  This introduces a minor issue
 in that this is no longer a parse error:

 import static::oops as Classname;

 However, if Classname is used, this will simply result in Fatal
 error: Class 'static::oops' not found in... and shouldn't be too big of
 a deal.  Also in the parser, I inserted T_IMPORT and T_NAMESPACE as
 aliases to T_STRING in global situations to allow for static method
 calls, class constants, and fully-qualified namespace calls.

 Basically this script is now possible with the patch:

 ?php
 namespace import;
 import ::Exception as Test;
 function import() {echo 'import function';}
 interface import {}
 interface fooey {}
 class Exception extends ::Exception implements fooey, import {}
 class namespace {
 const HI = 3;
 function list() {echo __METHOD__;}
 }
 import();
 var_dump(namespace::HI);
 namespace::list();
 ?

 and results in this output:

 [EMAIL PROTECTED]:~/workspace/php5$ sapi/cli/php -n testme.php
 import functionint(3)
 import::namespace::list

 I have not performed profiling on the patch, instead focusing on
 correctness for now.

 The patch looks complicated because of the additional states, but is
 really not that complicated, honest.

 :)
 Greg

 ? Zend/tests/zend_function_name.phpt
 Index: Zend/zend_compile.c
 ===
 RCS file: /repository/ZendEngine2/zend_compile.c,v
 retrieving revision 1.647.2.27.2.41.2.10
 diff -u -r1.647.2.27.2.41.2.10 zend_compile.c
 --- Zend/zend_compile.c 17 Oct 2007 10:01:21 -  1.647.2.27.2.41.2.10
 +++ Zend/zend_compile.c 23 Oct 2007 03:15:41 -
 @@ -2975,7 +2975,7 @@

 lcname = zend_str_tolower_dup(class_name-u.constant.value.str.val, 
 class_name-u.constant.value.str.len);

 -   if (!(strcmp(lcname, self)  strcmp(lcname, parent))) {
 +   if (!(strcmp(lcname, self)  strcmp(lcname, parent)  
 strcmp(lcname, static))) {
 efree(lcname);
 zend_error(E_COMPILE_ERROR, Cannot use '%s' as class name as 
 it is reserved, class_name-u.constant.value.str.val);
 }
 @@ -4582,7 +4582,9 @@
 if (((Z_STRLEN(name-u.constant) == sizeof(self)-1) 
   !memcmp(lcname, self, sizeof(self)-1)) ||
 ((Z_STRLEN(name-u.constant) == sizeof(parent)-1) 
 -  !memcmp(lcname, parent, sizeof(parent)-1))) {
 +  !memcmp(lcname, parent, sizeof(parent)-1)) ||
 +   ((Z_STRLEN(name-u.constant) == sizeof(static)-1) 
 +  !memcmp(lcname, static, sizeof(static)-1))) {
 zend_error(E_COMPILE_ERROR, Cannot use '%s' as namespace 
 name, 

Re: [PHP-DEV] Re: import/use last call

[Giedrius D]

On 10/23/07, Gregory Beaver [EMAIL PROTECTED] wrote:
  ?php
  namespace (Foo::Bar);
  import(new new);
 
 parse error - of all reserved words, only namespace and import are
 allowed as class names in my patch
Sorry missed that. Somehow I thought this applies only to functions.
Anyway allowing some keywords as class/function names and other not
adds some inconsistency to the language IMHO.

  // etc.
  ?
  Looks kinda odd to me although it might have sense in some context.
 
  Anyway my main question was: is there any reason not to use keyword use?
 The only reason for me is that use implies some kind of autoloading,
 as I suggested in one of my other mails.  This gets into parsing
 semantics, something I'm not interested in doing.
I guess it's the matter of background. To me import implies
autoloading where use doesn't.

 If the folks go with
 use that is fine, but for me personally not the best solution, which
 is why I put hours into making this patch.

 However, no matter what I definitely would like to see code written for
 PHP 5.2 and earlier that uses import or namespace as class names or
 functions continue to work in PHP 5.3.  namespace is used commonly for
 XML information (for obvious reasons), and import is a very common idea,
 as already stated.
I appreciate work but as I said above I think it adds inconsistency
and I think its not very good idea. I deffinetely agree that code
written for PHP 5.2 should continue to work in PHP 5.3. However this
patch is only one of possible solutions and it's up to you guys which
way to go.

Just a thought: maybe we should be discussing
namespace/name_space/something instead of import/use :-)

Just my 2 cents.

Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] T_IMPORT vs. T_USE

[Giedrius D]

Same here.

On 10/2/07, Ford, Mike [EMAIL PROTECTED] wrote:
 On 02 October 2007 07:16, Sebastian Nohn wrote:

  Andi Gutmans wrote:
   Hi Johannes,
   Our preference would be to stick to import because I
  think the perception many will have of use is that it also
  includes files (just based on some other languages).

 I don't know much about other languages, but purely in terms of English I 
 would expect use to work with something that's already lying around ready 
 to be used, whereas import would go and fetch something from somewhere else 
 and make it ready to be used in the current context. In other words, I would 
 probably expect import to potentially have an implied include, and use 
 not to.

 But then, in the global polyglot marketplace, this argument may not have much 
 force!! ;)

 Cheers!

 Mike

 -
 Mike Ford,  Electronic Information Services Adviser,
 JG125, The Headingley Library,
 James Graham Building, Leeds Metropolitan University,
 Headingley Campus, LEEDS,  LS6 3QS,  United Kingdom
 Email: [EMAIL PROTECTED]
 Tel: +44 113 812 4730  Fax:  +44 113 812 3211


 To view the terms under which this email is distributed, please go to 
 http://disclaimer.leedsmet.ac.uk/email.htm

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]

[Giedrius D]

 prefix Foo;
 alias Foo:Bar as Quux;

If namespaces have to be renamed, then IMHO this proposal is the best so far.

alias would also remove confusion from statement like ``import Foo``
because ``alias Foo`` is clearly no-op per se. At least to me ;-)

Regards,
Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]

[Giedrius D]

On 8/15/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:

  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]

[Giedrius D]

It isn't C++-like namespaces and it isn't Java-like packages. So it
doesn't really matters what name will be used. It will confuse
newcomers from any language anyway.

I came to PHP from C++ and I find my self confused from time to time
even though I code in PHP for a few years now. There are already more
then one thing in named just the same as in C++ but implemented
differently. One more thing woun't change anything.

FWIW, I vote for `namespace`.

BTW, if we are talking about the names already I have a question. Why
`import`? Why not `use`? AFAIK it's reserved and not used for anything
and IMHO it's better pair for `namespace`.


Regards,
Giedrius

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Question about Namespace patch

[Giedrius D]

On 7/23/07, Brian Moon [EMAIL PROTECTED] wrote:

David Zülke wrote:
 Oh yes, sure, that must be the main point about namespaces - I can use
 :: instead of _ as a delimiter! Yay!

If all you are going to do is:

?php

include MyClass.php;
import MyClass;

?

Then why use a namespace?  I really don't see the point.  Namespaces are
doing nothing for you in this case.


It is not always in your power to decide if you need namespace or not.
If you use
some lib from Vendor1 there's a good chance that all lib is in Vendor1 namespace
you want it or not.

If you use that Vendor1 lib in one.php file a lot you clutter your code with
Vendor1::A, Vendor1::B, Vendor1::C, etc. It is possible to rename Vendor1
to something shorter using import but you still have to prefix it.

Now as import has effect only in file where it was used it would be nice to
import all names from Vendor1 to the file one.php where it is heavy used and
not to the ones that include one.php.

So if the second.php file includes one.php global namespace is not
cluttered with
names from Vendor1 namespace. Only with names from one.php (if its names are
not in some namespace by them selves.) This way second.php may includeimport
some lib from Vendor2 to accomplish its tasks without even worrying about libs
used in one.php.

That's why people sometimes want to import *all* names from namespace.


Regards,
Giedrius

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Simple Namespace Proposal

[Giedrius D]

On 7/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:

 The other thing that bothers me is namespaces nesting. It was said
 that namespaces
 nesting is not supported. Then I'm missing a point in having namespace
 named A::B.

The same reason some people write $a = f($z, $t) and some write
$parsed_template = template_parser($template, $data_values) :)


I wasn't talking about a short/long names :-)
I was talking about a separator inside a namespace name.


 Lets say I have three files:

 a.php:
 ?php
 namespace A;

 function foo()
 {
 }
 ?

 b.php:
 ?php
 namespace A::B;

 function bar()
 {
//foo();
 }
 ?

 index.php:
 ?php
 require 'a.php';
 require 'b.php';

 import A;
 foo(); // should call A::foo(), right?
 B::bar(); // will this call A::B::bar()?
 ?

import A is a no-op. You do import A::B and then you can do B::bar.
import N means something that is named N can now be referred only by
it's 'last name' last(N), last name being last segment of the long
name. If you have short names, you don't need namespaces, but if you
have names like PEAR::DB::Record::Type::Modifier::Exception, you
probably do :)

 Now if this does not work then whats the point in having namespace
 A::B instead of A_B? IMHO this brings more confusion then
 clearness.

The point is you can a) omit namespace prefix inside namespace and b)
use just B (or C if you wish) instead of A::B outside, once you did
import. As I said, with long names it makes sense, with short ones you
are OK without it.

a) I was talking about namespace name A_B not class/function name.
b) So as far as I understand import doesn't actually *import* names
from specified
namespace to the current one but just renames long namespace name to a
shorter one. And if I get it right the separator in the namespace name
is allowed
and required only to express default name when importing without as.
Am I right?


Regards,
Giedrius

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Simple Namespace Proposal

[Giedrius D]

On 7/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:

 a) I was talking about namespace name A_B not class/function name.

_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm rather reluctant to start the my separator is
better than yours thread for the 42th time :)


Me neither :-) :: is perfectly good for me. I just missed the point of
having it more
then once if it's only purpose is to separate default short name part
from whole
name.


 b) So as far as I understand import doesn't actually *import* names
 from specified
 namespace to the current one but just renames long namespace name to a
 shorter one. And if I get it right the separator in the namespace name
 is allowed
 and required only to express default name when importing without as.
 Am I right?

Not exactly. It does import, but not names just one name - the very same
name it has as an argument. The :: is used to join components of the
name. Note that you can also do:

import Foo::XML as myXML;
$a = new myXML::Data::Document();


Now that explains a lot :-) If I get it right I can have namespaces
A::B::C and A::B::D
then create an alias for A::B with import A::B and use B::C::foo()
and B::D::foo() in
that file. Thats nice. Looks like namespace nesting though it isn't :-)


Regards,
Giedrius

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Simple Namespace Proposal

[Giedrius D]

Hi,

I read whole discussion and I'd like to share my opinion.


 Similarly, allowing multiple namespaces per file does not limit the
 developer in any way. Not allowing them does. I always thought a
 language should be designed to empower it's developers, not get in
 their way.

My opinion is that sometimes language *should* get in the way - if the
developer is trying to do a wrong thing. Doing things right should be
easy, doing things wrong should be hard. I agree that this means we
should choose some definitions for right and wrong, and not everybody
would necessarily agree, but I think the benefit of the clearer program
structure exceeds the disadvantage of not being able to do some tricks.
That's one of the reasons why PHP doesn't have some things that other
languages might have, such as nested classes, multiple inheritance or
closures.


I agree with Andrew Minerd. Language shouldn't get in developers way.
If its too
hard to implement then let it be. Most developers can live with that I
guess. However if
the only reason for this is so called clearer program structure then
I don't think
this limit is reasonable. There's no such thing as absolutely wrong
thing to do.
The thing that is wrong thing to do in one situation may be a good
thing to do in
other. One size *does not* fit all.


The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named A::B.
Lets say I have three files:

a.php:
?php
namespace A;

function foo()
{
}
?

b.php:
?php
namespace A::B;

function bar()
{
   //foo();
}
?

index.php:
?php
require 'a.php';
require 'b.php';

import A;
foo(); // should call A::foo(), right?
B::bar(); // will this call A::B::bar()?
?

If this works then we have a nested namespace here. The only thing
that's missing is
[commented] foo() call in A::B::bar() to be correctly resolve to
A::foo() as now it would
resolve to built-in function foo() if I understand it correctly.

Now if this does not work then whats the point in having namespace
A::B instead of A_B? IMHO this brings more confusion then
clearness.


Regards,
Giedrius

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php