from:"dukeofgaming"

How about the Yaml extension?, it looks well maintained enough:
http://pecl.php.net/package/yaml

Regards,

David

On Sun, Jun 5, 2011 at 2:33 AM, Hannes Magnusson hannes.magnus...@gmail.com
 wrote:

 On Sun, Jun 5, 2011 at 01:00, Andi Gutmans a...@zend.com wrote:
 
  In parallel I'd also see if there are any key extensions which we think
 are mainstream, stable and well maintained enough to be included. For
 example, http comes to mind.
 

 People have been afraid of suggesting new exts to core due to the
 policy of moving stuff from core to pecl, rather then vice verca,
 which has failed miserably.
 The only people who don't like our *bang* you have all you may
 possibly want approach are the python lovers.

 Gearman and memcache(d) are definitely something we should be bundling too.
 ZMQ is also imo a good candidate.

 -Hannes

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

Re: [PHP-DEV] JSON array/object syntax

Ok, I found that Ruby added support for a new JSONy syntax a little while
ago, this is interesting:

http://www.strictlyuntyped.com/2010/12/new-ruby-19-hash-syntax.html
http://webonrails.com/2009/02/06/ruby-191-hash/

But it doesn't have anything to do with JSON interoperability.

On Sat, Jun 4, 2011 at 11:32 AM, Anthony Ferrara ircmax...@gmail.comwrote:

 One advantage would be familiarity.  New developers only need to worry
 about 1 syntax, rather than a new one for each language.  I'm not
 saying if it's worth it or not, but there is something to be said for
 consistency and using already established patterns and syntaxes if it
 makes sense (aka: there is no compelling reason not to).  So far I
 haven't seen any compelling reason not to do it.  Not saying they
 aren't there, nor that there aren't justifiable reasons in the
 threads.  Just that I don't find any of the reasons against it
 compelling enough to say it doesn't make sense to use a json-style
 syntax.

 Just my 0.02...

 On Sat, Jun 4, 2011 at 7:52 AM, David Zülke
 david.zue...@bitextender.com wrote:
  To clarify: I don't understand what the advantage would be, either. It
 seems that those demanding it somehow confuse or blur the lines between the
 declaration of data in the language and its representation in a
 serialization format. A few people in the thread demanded that it be a
 syntax that could also be consumed by all the JSON parsers out there, and I
 have no idea how that would be useful at all, since the construct per se
 isn't useful at all as PHP code and at least needs to be wrapped in ?php
 and ? tags, so you couldn't just evaluate it as JavaScript (which would be
 useless without assignment etc).
 
  I ignored that aspect as others covered it already (e.g. Pierre asking
 what the point was of this at all) and focused on the encoding issue that
 *would* occur if someone, somehow managed to find a useful way of taking
 advantage of such a notation (e.g. where it would be interchangeable with JS
 code or be evaluated as JSON by other JSON parsers) - namely the problem
 that you could produce *PHP code*, that, with some mingling and stripping,
 *PHP's own json_decode() could not process*.
 
  Perhaps I should have made that more clear, sorry.
 
  David
 
 
  On 04.06.2011, at 03:17, dukeofgaming wrote:
 
  Hi,
 
  After reading all the debate in the other thread it is still not clear
 to me
  what the real advantages are of adopting JSON syntax for native PHP
  types. Doing json_encode to an object and expect the code and output to
 be
  the same seems useless to me, and reading David Zülke's example it seems
  more like a pure-unicode issue to me:
 
  
 
  It is different from writing json_decode('ä\u0123'), because
 json_decode()
  in PHP only accepts UTF-8 encoded input;
 
  Give it a shot:
 
  ?php
  $chr = \xC3\xA4; // ä as UTF-8
  var_dump(json_decode('[' . $chr . '\u00e4]'));
  var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
  ?
 
  That'll produce:
 
  array(1) {
   [0]=
   string(4) ää
  }
  NULL
 
  Understand what the problem is now?
 
  If someone does this in a latin1-encoded file:
 
  ?php $fancyNewArray = {yay: ä}; ?
 
  Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but
  cannot be consumed by PHP's json_decode(). And that would be terribly
  inconsistent behavior.
 
  -
 
  It looks more like you want to do json_decode to PHP code hoping that
 will
  somehow fix json_decode... instead of fixing json_decode.
 
  Could someone advocating this please explain with use-cases and concrete
 
  punctualized examples the advantages of having such JSON approach to
 PHP.
 
  Regards,
 
  David Vega

Re: [PHP-DEV] Object and Array Literals

I like the idea of supporting both = and :. Would this work?:

  $foo = {
'bar' : function(){
   echo 'baz';
}
  };

  $foo-bar();

And I'm guessing this shouldn't work:

  $array = array('foo' : 'bar');

Regards,

David

On Sun, Jun 5, 2011 at 4:11 PM, Chris Stockton chrisstockto...@gmail.comwrote:

 Hello,

 On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano j.boggi...@seld.be wrote:
  Thanks for working on this.
 
  On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
  Please read, and if you have a comment that is not already covered in
 the RFC, raise it here. I'm definitely open to discussion, but I would
 really love to keep this discussion civil.
 
  TBH, I dropped half-way through the original topic, so I'm sorry if I
  missed something, but why don't we just treat {foo:bar} as an
  array? json_decode() can do it, and it makes complete sense since PHP
  arrays are hashes too. I don't see much benefit to having this create
  an object by default, especially since even if you use that notation
  to send data to a JSON API, json_encode'ing a hash will create an
  object.
 
  It's the only pain point I really have, that I can't use true
  json-syntax without ending up with this messy pile of objects/arrays
  mixed together. If we do this, IMO the hashes should not be able to be
  defined with [], but that'll probably upset people, so I don't really
  care if it is possible.
 
 • Strictness of unquoted keys.
 
  This is just legacy crap honestly, if we make up new syntax, we
  shouldn't include the old mess in it. I think everyone is quoting
  their strings by now..
 
 • Support = in addition to : as a key:value separator.
 
  Same as my point on [] above, I think adopting the JSON notation
  should be done fully, keeping this stuff in might be ok to make people
  happy, but it does not make much sense.
 
 • possibility of simply not supporting the \u### syntax for
 Unicode characters in literal strings (just like the rest of PHP).
 
  This is still PHP strings, they should behave as such. Sounds good to me.
 
 • Should mixed-format (numeric and associative arrays) be
 allowed? (e.g. [1,'two':2, 3])
 
  Assuming we keep [] to arrays and {} to hashes as I said above, I'd
  say no. In the rare cases that it is useful you can still use array()
  if you really feel this is necessary..
 
  I'm sure many people will disagree with this, and I don't really mind
  how it ends up syntactically speaking, but please really consider
  dropping the stdClass part, that'd really suck :/
 
  Cheers

 I think there is a clear benefit to allow {} as well as [] being
 StdClass and array respectively. However, I understand your point as
 well as the point of others when they speak of the usefulness of
 StdClass, really this tells me perhaps we should look at adding some
 basic enhancements to StdClass (I.E. some methods for example), or
 perhaps a new class for default object creation. At the very least
 maybe a way to specify the default class.

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

Re: [PHP-DEV] Object and Array Literals

On Sun, Jun 5, 2011 at 6:06 PM, Sanford Whiteman 
sa...@cypressintegrated.com wrote:

 -- I do not feel that the acronym JSON has any clarifying nor edifying
 place in the RFC describing this syntax.

 Rather, I would suggest one of the following:

 · JavaScript-like [object|array] literal syntax
 · bare-bracket [object|array] literal syntax
 · short [object|array] literal syntax
 · compact [object|array] ...
 · quick [object|array] ...
 · colon-pair [object|array] ...

 I have actually been excited about the discussion of this feature area
 and anticipate my eventual +1 if JSON could be removed from the RFC.
 Even  though  the  term  doesn't  affect the way the feature works, by
 upvoting  the  RFC one is approving of wording that may make it to the
 general public, and I think this would be bad for PHP.


 It  might  also  be  noted (h/t David Vega) that Ruby adopted a syntax
 similar  to  that  proposed here and completely avoided using the term
 JSON  in  final documentation, as I hope will be done with PHP even if
 this RFC continues to use the term.


Bravo for ponting that out, your argument has cleared my mind a little while
trying to understand this side (I'm actually against the JSON
interoperability argument [because it does not make sense to me], but not
the syntax).

After reading this new RFC and pondering about the JSONy implications, the
multi-part conclusion that I reached is that:

a) JSON is actually being mentioned to advocate for the syntax with for the
sake of *familiarity*.

b) Interoperability is being confused with familiarity.

c) Actual interoperability of the syntax with JSON is just a happy
coincidence (same as with Ruby)

d) In no context this notation could function as JSON and PHP at the same
time, mainly because PHP requires tags

e) There is a strong resistance to change, I bet the detractors of this
short syntax (even with the :) would change their opinion after using it,
just the way some of us used to hate the idea of namespaces with \ and
after using it changed our opinion (specially with the autoloading standard
that actually reflects file structure, e.g. in Symfony2).

f) If JSON ceased to exist in this very moment, supporters of the syntax
would be still supporting it and perhaps detractors would accept it.

The effect of mentioning JSON, and implying direct compatibility with JSON
technologies and JSON itself is just adding FUD.

+1 to removing references to JSON from the RFC, because [ ], { } and :
make enough sense by themselves.

Regards,

David Vega

Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)

2011-06-03 Thread dukeofgaming

How about a separate email topic dedicated to voting?, that would reduce the
signal to noise ratio for votes (and increase it for opinions).

Regards,

David

On Fri, Jun 3, 2011 at 10:25 AM, Martin Scotta martinsco...@gmail.comwrote:

  Martin Scotta


 On Fri, Jun 3, 2011 at 5:16 AM, Pierre Joye pierre@gmail.com wrote:

  hi Derick,
 
  On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote:
   On Thu, 2 Jun 2011, Stas Malyshev wrote:
  
   I'd like to set up a vote for the undecided TODO features on
   wiki.php.net, anybody could help me with setting up the voting module
   there if there's such thing on the wiki? Or set me up with the access
   to wiki machine and I'll install it :)
  
   Voting on the wiki? Yuck. If you want participation, do it here on the
   mailinglist and store the record in the wiki. If all votes are
 showing
   up just in the wiki then there is no exposure on the list and things
 are
   easy to miss (especially with the huge amount of noise that's already
 on
   the list).
 
  Please re consider your opinion like noises on the list and other
  similar statements, thanks.
 
  As of the votes in the wiki, it is perfectly fine and valid, easy to
  manage and open. Much more easier than counting random votes in the
  ML, especially when discussions are split in many threads. The
  discussions and related activities do happen on the list and that's a
  good thing.
 

 Yes, but only who has wiki karma are allowed to vote.


 
  --
  Pierre
 
  @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] JSON array/object syntax

2011-06-03 Thread dukeofgaming

Hi,

After reading all the debate in the other thread it is still not clear to me
what the real advantages are of adopting JSON syntax for native PHP
types. Doing json_encode to an object and expect the code and output to be
the same seems useless to me, and reading David Zülke's example it seems
more like a pure-unicode issue to me:



It is different from writing json_decode('ä\u0123'), because json_decode()
in PHP only accepts UTF-8 encoded input;

Give it a shot:

?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?

That'll produce:

 array(1) {
   [0]=
   string(4) ää
 }
 NULL

Understand what the problem is now?

If someone does this in a latin1-encoded file:

?php $fancyNewArray = {yay: ä}; ?

Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but
cannot be consumed by PHP's json_decode(). And that would be terribly
inconsistent behavior.

-

It looks more like you want to do json_decode to PHP code hoping that will
somehow fix json_decode... instead of fixing json_decode.

Could someone advocating this please explain with use-cases and concrete 
punctualized examples the advantages of having such JSON approach to PHP.

Regards,

David Vega

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

2011-06-02 Thread dukeofgaming

State the case for JSON in a separate RFC and progress will be made, but I
think there is a fundamental mistake here: serialization formats are the
*means* for interoperability, not the ends.

The only way I see JSONy syntax would help is if PHP code —with JSONy
syntax— would be parsed by a JSON parser, and I don't think that is likely
to happen... if you want PHP to have a data structure behave like JSON that
is another story.

Add use cases, syntax descriptions, and perhaps a patch for this JSON RFC
and the main argument will be better understood; an RFC will help, visceral
statements and personal attacks, on the other hand, won't, so I bet your
time —and everybody else's— will be better spent in writing an RFC to defend
it.

Regards,

David

On Thu, Jun 2, 2011 at 4:22 PM, Pierre Joye pierre@gmail.com wrote:

 On Thu, Jun 2, 2011 at 10:19 PM, Sean Coates s...@seancoates.com wrote:
  If people vote on this now, will further discussion about how this
 SHOULD
  work be shut down with we already voted on this?
  which other discussions do you wish? Json is clearly not an option and
  not enough people (but a couple) likes or wants it.
 
  The RFC is about short array syntax and as far as I can see there is
  already a clear consensus for one of the proposed new syntax.
 
  I don't see why JSON (or JSON-like, or JavaScript Object Literal, or
 whatever the least politically-fired term of the moment) syntax is clearly
 not an option. I'm considering writing a new RFC that calls for first-class
 JSONishy syntax, but I have better things to do if it's already dead in the
 water.
 
  As much as I'd like to avoid drawing out this discussion, I think a
 premature vote that will be used as a political wedge to shut down all
 future syntaxes that don't use T_ARRAY is not in the best interest of PHP.

 You can still vote -1 on this RFC and try to block it. That's the
 purpose of the votes. But arguing endlessly why json-like syntax is
 better without an alternative RFC and patch won't bring you anywhere.


 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[PHP-DEV] Wiki editing privileges

Hi,

I remember having wiki editing privileges not so long ago, I was going to
enter and add the entry for discussions at
https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
Would it be too much to ask to have them enabled?.

Best regards,

David Vega

Re: [PHP-DEV] DVCS

Hi,

I thought it might be interesting for all to read some feedback I got from
some questions I made to the Joomla community, specifically, the guys and
gals that have been implementing the decoupling of the Joomla framework: the
Joomla Platform.

They currently still use svn officially but they have been experimenting
with both mercurial and git. These are their responses so far:

http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e

It may bring some insight to what a DVCS could do for the PHP community.

Best regards,

David

On Thu, Apr 28, 2011 at 2:28 AM, Lester Caine les...@lsces.co.uk wrote:

 dukeofgaming wrote:


 http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080

 So, I don't want to make debate here of wether centralized is better than
 distributed (because the point is moot), but I think its not a good
 situation for the community to have a previously open door to DVCSs now
 closed.


 Having been battling with various projects that have decided that 'git is
 good' or 'hg is best' ... I've been trying to live in the new world and
 failing. That link is looking like a nice CURRENT overview of the situation
 although things are still changing mainly for the good.

 My problem until recently was that 'subrepo' management in DVCS has always
 been playing catchup. Yesterday for the first time I checked out a
 'super-project' matching one of the composite builds provided on an original
 CVS repo! Still not fully integrated into Eclipse, but hopefully even that
 will come with time. But now I can 'clone' the half dozen different builds
 and manage them in parallel with both github and bitbucket 'masters'.

 I'm using Mercurial and TortoiseHg which almost work transparently between
 Linux and Windows, and with hg-git access to the 'git is good' projects is
 also transparent even on windows. Next step this weekend IS to tidy up the
 SVN setup so that I have the PHP code locally mirrored as well 

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php


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

Re: [PHP-DEV] Wiki editing privileges

Thanks, I also don't think that was the case.

Regards,

David

On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson phi...@roshambo.org wrote:


 On May 31, 2011, at 11:05 PM, dukeofgaming wrote:

  Hi,
 
  I remember having wiki editing privileges not so long ago, I was going to
  enter and add the entry for discussions at
  https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
  Would it be too much to ask to have them enabled?.

 I don't think anyone [intentionally] took away wiki editing rights, but you
 now have full access to the rfc namespace.

 Regards,
 Philip

Re: [PHP-DEV] DVCS

Hi Lester,

AFAIK both mercurial and git support sub-repositories nicely now:

http://mercurial.selenic.com/wiki/Subrepository
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html

Regarding the graphical tools, I don't use them that much, but I see your
point. Personally, I just occasionally use the Netbeans integration because
it is easier to commit files in separate directories, but that is pretty
much it since I think the rest is easier and quicker to do with the console,
but I guess it will always be a matter of personal preference.

I've been working with hg subrepos and they are quite nice. I'm still not
that familiar with git submodules.

BTW, you don't need to use python to customize/extend mercurial's behavior,
you can use hooks: http://mercurial.selenic.com/wiki/Hook

Best regards,

David

On Wed, Jun 1, 2011 at 1:56 AM, Lester Caine les...@lsces.co.uk wrote:

 dukeofgaming wrote:

 I thought it might be interesting for all to read some feedback I got
 from some questions I made to the Joomla community, specifically, the
 guys and gals that have been implementing the decoupling of the Joomla
 framework: the Joomla Platform.

 They currently still use svn officially but they have been experimenting
 with both mercurial and git. These are their responses so far:


 http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e

 It may bring some insight to what a DVCS could do for the PHP community.


 I think that there are perhaps still a couple of separate problems here
 which the DVCS community need to get behind for any of them to become a
 'front runner'.

 The main problem here IS 'subrepo' which is a concept that neither HG or
 GIT handle particularly well, but to my mind is essential for a very much
 modular project like PHP! While I have sort of managed to put together a
 'checkout' of a set of packages which together make a single build of the
 target project, I'm still having to pull and commit changes manually to each
 subrepo - I don't get the simple overview of outstanding changes that was SO
 nice to work with in CVS! To try and put this in a 'PHP' context ... I DID
 have a list of extensions I was working with, and a 'sync' in ECLIPSE gave
 me a nice list of which ones had had changes pushed ... I could then go and
 either simply update to those changes on an extension by extension basis -
 or review the changes in each file so allow me to integrate other peoples
 changes with my own local 'tweaks'. This is something that DVCS SHOULD be
 perfect for, but the management tools for bundling a selection of parts of a
 project are not there yet, mainly because the core developers on both HG and
 GIT don't see then need because they don't need that type of working!


 I'm limping along with HG at the moment simply because it works on both
 Linux AND Windows, while GIT's windows support is still rather hit and miss
 when one is already using other unix tools on windows, but I do not have the
 same level of integration in Eclipse that CVS and SVN provide beautify
 straight out of the box. At least I can drop out of Eclipse into TortoiseHg
 and do the code management, but it's not an ideal way of working.

 If I was a 'console jockey' then much of this would probably be a lot less
 of a problem. One seems to need to write scripts to do what YOU want to do
 in both HG and GIT - and then need to learn Python to do that in HG :( But I
 never used CVS from the command line so a LOT of the reasoning for even the
 switch to SVN was irrelevant since Eclipse had already solved all of those
 'problems'.

 At the current time I think that PHP would need to restructure how it is
 packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd
 still prefer CVS here it works BETTER as a master for DVCS! ) as the master
 from which we CAN currently sync using HG or GIT is the best of a bad job
 currently. Unless some knows better?


 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] Wiki editing privileges

Hmm, I can edit pages within the RFC namespace but I cannot edit
https://wiki.php.net/rfc.

Regards,

David

On Wed, Jun 1, 2011 at 1:38 AM, dukeofgaming dukeofgam...@gmail.com wrote:

 Thanks, I also don't think that was the case.

 Regards,

 David


 On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson phi...@roshambo.org wrote:


 On May 31, 2011, at 11:05 PM, dukeofgaming wrote:

  Hi,
 
  I remember having wiki editing privileges not so long ago, I was going
 to
  enter and add the entry for discussions at
  https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit
 anymore.
  Would it be too much to ask to have them enabled?.

 I don't think anyone [intentionally] took away wiki editing rights, but
 you now have full access to the rfc namespace.

 Regards,
 Philip

Re: [PHP-DEV] DVCS

On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine les...@lsces.co.uk wrote:

 Drak wrote:

At the current time I think that PHP would need to restructure how
it is packaged up to provide a single repo in both HG or GIT.
Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
for DVCS! ) as the master from which we CAN currently sync using HG
or GIT is the best of a bad job currently. Unless some knows better

 I know what you mean.  There are solutions like submodules in GIT but it
 does require some small restructuring usually.  By the way, TortoiseGIT
 is now quite excellent for Windows GUI.  A new version 1.7.0 is just
 about to be released too.  I'm a bit biased against GIT but overall, GIT
 is getting way more traction than Hg and github.com http://github.com

 excels in features compared to anything else.

 When TortoiseGIT runs in Linux as well - they will have caught up!
 TortoiseHg works transparently in both and on Mac I believe. My customer
 base is mainly windows biased while I've been running on Linux here for some
 years now. I need both platforms to do the same thing - which Eclipse has
 provided for several years, but the DVCS camps still need to address.
 Windows GIT is something different from Linux GIT at the moment - which is
 probably all that is putting me off it. Actually when I was forced to used
 GIT the windows side simply did not work at all, so I HAD to use hggit to
 get anything!


   From what I have seen also, IDE integration with GIT is starting to
 catchup both in NetBeans and Eclipse - and already way ahead of the pack
 is phpStorm for VCS integration, but it's not free.

 hggit + Mercurial Eclipse + Eclipse means I could not care less what the
 target is EXCEPT that one can't write a project that is JUST the set of
 sub-modules that you want to pull together. IDEALLY - both GIT and HG would
 just pull stuff from which ever is providing a particular library? So say
 Smarty could be on one while ADOdb is on the other ... The core PHP code
 does not need to be so distributed, but being able to pull PECL modules from
 a number of sources to add to a core clone of the code could be useful?


Perhaps, it would depend how teams are structured, but even it was a single
repository for everything I think stuff would work fine.

My opinion is that the reason behind sub-repositories is to include code
from vendors, not that much to modularize development of a single big
project, why?, because of the distributed nature of a DVCS: imagine that
there is a PECL team, and that team makes a fork of the main PHP repository,
and they focus on that fork (every separate repository can be regarded as
a fork) and they handle all their work integration, and then someone (after
an ammount of work is done) pulls back from the main repo (the one where
last integrations are agreed to be added, central if you must call it
that) to ensure everything still runs ok, and then ask to the final
integrator to pull and merge their work: done.

Oh, and HG supports svn and git as subrepos now.

Regards,

David

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

After that argument, I think I'm against : now too. +1 to =

Could { } be implemented for objects too then?.

Regards,

David

On Wed, Jun 1, 2011 at 4:36 AM, Ford, Mike m.f...@leedsmet.ac.uk wrote:

  -Original Message-
  From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
  Etienne Kneuss
  Sent: 01 June 2011 01:57
  To: internals@lists.php.net
  Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
 
  +1 for a short array syntax.
 
  But only if you keep it consistent, PHP has always been using = for
  key/val association, I don't see any reason to suddenly provide
  key:
  val, unless what you want is to confuse people.

 Hear, hear and hear, hear to that!

 ['a': 'b'] just feels completely un-PHP-like, and I'd be totally
 against it.

 If the desire is to have a native JSON syntax so that you can eval()
 imported JSON, then I'm completely anti that, too -- that's a case
 where I'd far rather be explicit and use json_decode(). And since, no
 matter how you slice it, you're never going to get a complete fit
 between native PHP structures and JSON encoding, I don't believe you
 should even try.

 I just can't see the problem with saying: PHP arrays (and maybe
 objects?) look like *this*, and if you want to import/export them
 from/to a JSON representation, there are functions to do it like
 *this*. This seems to be the perfectly sensible approach of other
 languages I've used recently (although my perl is somewhat out-of-date,
 and my python even more out-of-daterer and minimal at that!). Even
 ECMAScript is going down the route of explicit conversion with
 JSON.parse() and JSON.stringify() in ECMAScript 5!

 All in all, still +1 for [1, 2=2, 'a'='b'], and -several million (for
 style) for any syntax involving colons.

 Cheers!

 Mike
  --
 Mike Ford,
 Electronic Information Developer, Libraries and Learning Innovation,
 Leeds Metropolitan University, C507 City Campus,
 Portland Way, LEEDS,  LS1 3HE,  United Kingdom
 E: m.f...@leedsmet.ac.uk T: +44 113 812 4730






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

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye pierre@gmail.com wrote:

 Reminder: Pls add your votes here:
 https://wiki.php.net/rfc/shortsyntaxforarrays/vote


Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.

Best regards,

David Vega

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Wed, Jun 1, 2011 at 2:38 PM, Philip Olson phi...@roshambo.org wrote:

  Reminder: Pls add your votes here:
  https://wiki.php.net/rfc/shortsyntaxforarrays/vote
 
 
  Who is allowed to vote?, are userland votes still going to count?, if
 so,
  how does one qualify as userland voter?.

 
  I think the one that is active can be a voter.
  Or maybe the ones that have any karma on php environment is considered a
 voter.

 I'm choosing to ignore this voting mechanism because it feels wrong. And
 besides, this RFC is outdated and still being reviewed for comments. In
 other words, nobody knows what they are voting on.

 Regards,
 Philip


Yup, it feels rushed. The RFC should be cleaned up and I think this are the
main items:

- Ditch :
- Ditch the JSON topic or open a separate RFC with it
- Introduce the { } syntax for objects and change the title

Regards,

David

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you jsony object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the *BEHAVIOR*
 of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
*look* like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way ?= and ? were.

Could someone get Douglas Crockford in here?, rofl.

Regards,

David

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Hi,

I'm glad the topic has been picked up again, but I think there is an
inconsistency in the proposal now that we are talking about being JSON-ish:
JSON describes objects, not arrays. Then, what if [] were used for arrays
and {} for objects?, so that:

[1,2,3] //array(0=1, 1=2, 2=3)
['one':1, 'two':2, 'three' : 3] // array('one'=1, 'two'=2, 'three' = 3)
['one':1, 'two':2, 'three' : 3] // (object)array('one'=1, 'two'=2, 'three'
= 3)

Regards,

David

On Tue, May 31, 2011 at 4:25 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!


  Stas, I didn't understand your point about eval() and security. What did
 you mean?


 I meant if PHP has JSON syntax as native, e.g. you can say something like:

 $a = {a:b};

 Then the temptation would be to write something like:

 // $json_string is {a:b}
 $a = eval($json_string);

 just as Javascript programmers sometimes do. That would have the same
 security implications as it has in Javasctipt - somebody could inject
 executable code there, etc. Of course, nobody forces you to do this, but the
 temptation would be there.

 Also, with full JSON support it is not entirely clear to me what {a: b}
 would mean - is it an array or an object? In JS, it's definitely an object,
 but in PHP objects are almost never used to store pure state without
 behavior, because we have hashtable arrays, while JS only has vector arrays.
 So here we have some unclear point (which does not happen with [] syntax,
 since with [] it's obvious we're talking about arrays, just as in many other
 languages).

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Tue, May 31, 2011 at 4:36 PM, dukeofgaming dukeofgam...@gmail.comwrote:

 Hi,

 I'm glad the topic has been picked up again, but I think there is an
 inconsistency in the proposal now that we are talking about being JSON-ish:
 JSON describes objects, not arrays. Then, what if [] were used for arrays
 and {} for objects?, so that:

 [1,2,3] //array(0=1, 1=2, 2=3)
 ['one':1, 'two':2, 'three' : 3] // array('one'=1, 'two'=2, 'three' = 3)
 ['one':1, 'two':2, 'three' : 3] // (object)array('one'=1, 'two'=2,
 'three' = 3)


Err, I meant:

{'one':1, 'two':2, 'three' : 3} // (object)array('one'=1, 'two'=2, 'three'
= 3)

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Guys, as I said earlier, not even javascript (from javascript object
notation, as in JSON) is 100% interoperable with JSON because single quotes
are valid in javascript and not in json. I say : is way more cleaner than
= and it is a good opportunity to adopt it.

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

On Tue, May 31, 2011 at 7:29 PM, Dan Birken bir...@gmail.com wrote:

 +1

 To be honest, ['a': 'b'] or ['a' = 'b'] is so much better than array('a'
 =
 'b') for general use I don't even care which one is picked, as long as one
 of them is picked.

 -Dan


+1 to that too. Even when I've never liked that much = and would love to
see : make an entrance instead .

I'm afraid that if : is associated with the JSON interop argument and the
later is discarded then : will be discarded too, much like what happened
with the echo shortcut (?=) and the short tags (?). Perhaps the idea
of JSON interop could be taken to another RFC and get less noise and better
ideas as a separate topic.

Regards,

David

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

On Tue, May 31, 2011 at 9:27 PM, Rasmus ras...@lerdorf.com wrote:

 On 05/31/2011 05:42 PM, dukeofgaming wrote:

  I'm afraid that if : is associated with the JSON interop argument and
 the
  later is discarded then : will be discarded too, much like what
 happened
  with the echo shortcut (?=) and the short tags (?). Perhaps the
 idea
  of JSON interop could be taken to another RFC and get less noise and
 better
  ideas as a separate topic.

 ?= has been decoupled from short tags in 5.4 and is always available.

 -Rasmus


Yep, I know, and thank you very much for that (I did see your commit a
couple of hours after you posted it). I think there was a lot of confusion
and fear (myself included) when ? were deprecated, e.g. the Kohana
project used to have them and recommend them too, but they removed the
practice later and stopped recommending them.

Anyhow, I think : vs = is the only thing left to decide on this
proposal. I was thinking that if : was to be introduced, perhaps
array('a':'A',...) should also be added for consistency, and that is extra
work. In my opinion adopting : would be nice, but it would also be noise
for the developer community, perhaps good noise but noise nonetheless.

The healthy thing to do here IMHO, would be putting introduction of : as a
separate RFC, perhaps part of a JSON interoperability RFC, but as Adam just
replied, PHP is not JSON and = is a very fundamental thing to change, so
I have mixed feelings about this.

Also, can we agree on the topic of introducing { } for objects to the
proposal?.

Best regards,

David

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Also, take a peak at this: http://www.phpsadness.com/sad/45

And compare it with this:
http://perldoc.perl.org/perldsc.html#Declaration-of-a-HASH-OF-COMPLEX-RECORDS

Regards,

David Vega

On Wed, Jun 1, 2011 at 12:15 AM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!


  I agree, it would be a break a lot of code. But I'd rather see some
 fundamental changes at that level (call it PHP 6, make it not BC with
 PHP 5.x or earlier), and remove the cruft and standardize on some of
 the slop.


 Fundamental changes means throw out your production code and start
 developing a new one. Guess how many PHP shops with existing code would be
 happy to do it. It's nice to rant about how PHP function are inconsistent
 and stuff, but no project was seriously impeded by it ever. At most it is
 mildly irritating. Huge BC break, on the other hand, would mean all major
 apps/libraries/frameworks become instantly not available, and who knows when
 they catch up. At this point, you might as well have a new language.


  Shorter array syntax seems like an unnecessary addon, will create more


 Since many experienced people are supporting it, I'd think that while it
 seems unnecessary to you, it may seem otherwise for them.


  I would help with the Unicode project if I could. I am not sure why it
 was so tough, but I imagine people infinitely smarter than I am were


 Read this (esp. first answer):
 http://stackoverflow.com/q/6162484/214196

 It's about Perl, but gives you an impression why it is so tough.


  Making JSON style arrays seems stupid to me. When I look at a PHP
 script I expect PHP syntax. Not stolen pieces from a bunch of other
 languages (yes, some of it is that way already, but let's not keep the
 trend going please?)


 Why not? If the pieces are good, stealing them is good. It's how progress
 happens - you steal good pieces and add couple of your own, and hope the
 result is good enough that somebody else would want to steal stuff from it
 :)

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

On Wed, Jun 1, 2011 at 12:35 AM, Michael Shadle mike...@gmail.com wrote:

 I don't really want to stand on my soapbox any longer, as it's obvious
 where the crowd leans on this one, but I need to clarify a couple
 points a bit and feel obligated to reply to another.

 On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev smalys...@sugarcrm.com
 wrote:

  Fundamental changes means throw out your production code and start
  developing a new one. Guess how many PHP shops with existing code would
 be
  happy to do it. It's nice to rant about how PHP function are inconsistent
  and stuff, but no project was seriously impeded by it ever. At most it is
  mildly irritating. Huge BC break, on the other hand, would mean all major
  apps/libraries/frameworks become instantly not available, and who knows
 when
  they catch up. At this point, you might as well have a new language.

 This is understood, but it was a crackpot example. IMHO, adding more
 ways to express the same thing in a well-established language is more
 or less the same. It's relearning something you thought you already
 knew; yes, one breaks BC, but that is why you'd have to classify it a
 different major version. I'm done on that one. Like I said, it's a
 crackpot example.

  Since many experienced people are supporting it, I'd think that while it
  seems unnecessary to you, it may seem otherwise for them.

 Many experienced people are also against it.


AFAIK, it was because they didn't want to maintain/implement it. Don't know
if this was before the patch was provided.



 If a handful of experienced people decided to go forward with my
 crackpot idea above, would you be in support, just because they are?

 Also, you're implying that this is a *necessary* change for these
 experienced people. Is there something I am missing that PHP is *not*
 handling currently and requires this *necessary* change? (No)

  Read this (esp. first answer):
  http://stackoverflow.com/q/6162484/214196
 
  It's about Perl, but gives you an impression why it is so tough.

 I figured it was tough, based on the amount of effort/time people
 spent. Sad to see that it seems abandoned though.

  Why not? If the pieces are good, stealing them is good. It's how progress
  happens - you steal good pieces and add couple of your own, and hope
 the
  result is good enough that somebody else would want to steal stuff from
 it

 While a language is maturing, I would probably agree. I consider PHP
 quite mature now. I'd say the proof is in the pudding based on the
 numbers.

 My chief concerns are these:

 IMHO, JSON-style syntax is *not* as readable as PHP array syntax. It's
 shorthanding something that is pretty short as well.

 Currently, if I want to find an array in code, I can search just for
 array or Array or = or variations thereof. This adds yet
 another type of grep I have to run through. One that I am not sure can
 be easily accomplished (wouldn't it be matching quite a lot more
 because of it's bare nature? Now we've got to look up neat ways to
 combine and grep for :?[]{} etc.) Also, now you have coders on the
 same project using their personal preference.


 If something isn't broken, why fix it? That was the basis on my
 original comment about things that actually were underway or brought
 up due to issues.

 Before I get off my sandbox, and go back to the shadows on the dev
 list, someone privately replied to me and said this will help because
 it will its hurting lots of people's eyes (and wrists on the long
 term) - I'm taking that as a joke.


Weird, I didn't mean to reply privately, must have mistaken the reply to all
button. Anyhow, I did say it tongue-in-cheek, but the shorter syntax is
easier on the eyes for the nested case. Just FTR I'll copy most of my email
here:


Stolen?, why not learned?. Java has great architectural stuff and if wasn't
for other languages (and developers educated on them) we wouldn't have stuff
like exceptions, reflection, and —in the future— traits. You write as if PHP
could not or should not improve, and that is a very wrong attitude to have
IMHO.

The shorter syntaxes are more readable and thus an improvement. You said:

Is it hurting anyone to type out array() or something?

I say its hurting lots of people's eyes (and wrists on the long term, tsk
tsk). But its not going to be an obligatory syntax, you will always be able
to use array() if you enjoy it; personally, I don't, and I don't think the
proposers and supporters enjoy it that much either.

---

Regards,

David

Re: [PHP-DEV] Constructor object instance dereferentiation

2011-05-22 Thread dukeofgaming

On Sun, May 22, 2011 at 3:16 AM, Ferenc Kovacs i...@tyrael.hu wrote:


 hi.

 it was already discussion, Felipe created an RFC and a patch, the responses
 was all positive, so I think if nobody changed their mind, we could move
 this from Under Discussion to Accepted/Implemented
 as I said before, it would be in good pair with the already implemented
 array dereferencing (https://wiki.php.net/rfc/functionarraydereferencing)

 http://marc.info/?l=php-internalsm=129080024516125w=2
 https://wiki.php.net/rfc/instance-method-call

 Tyrael


Hi,

Nice, it would indeed make sense to include it with array dereferencing.
This feature would enter in the PHP 5.4 release along with array
dereferencing, is this correct?.

Regards,

David

[PHP-DEV] Constructor object instance dereferentiation

2011-05-21 Thread dukeofgaming

Hi,

I was wondering if object dereferentiation after constructor call is
something that has been discussed already. This is, being able to do
something like:

new MyClass()-setSomething();

Instead of:

$var = new MyClass();
$var-setSomething();

Regards,

David Vega

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

2011-05-19 Thread dukeofgaming

@Michael

Those are interesting ideas, I think you can register by yourself on the
wiki, so you can add the RFC. OTOH, and again, I must say I really think the
echo shortcut should be regarded as a separate issue, and now that there was
some consensus we shouldn't deviate from the topic.

In the end I think it is going to be as bad to have short open tags turned
off by default. Hosting services still meddle with the php.ini and some even
let you make your own customizations to it (or at least to a subset of it).

But again, can we first agree on the echo shortcut feature to be decoupled
from short tags?. No agreements === no progress.

BTW, what is your open source project?

@Thomas

I agree on dropping % for good, I personally don't know any project that
uses it and don't think there is currently any point to them anymore.

Also, I do use '? ' instead of '?' (originall I thought it might throw an
error, then it became habit), although I try not tu use ? as much as ?=.
Having the space as a requirement (i.e. ?for(... would throw an error)
would fix the XML situation, is this what you are saying?.

@all

Can we decide on decoupling ?= before going back to the general short tag
matter?

On Thu, May 19, 2011 at 10:35 AM, Thomas Hruska thru...@cubiclesoft.comwrote:

 On 5/19/2011 12:23 AM, Arvids Godjuks wrote:

 It's essentially the same what I said - move it out of stort_tags and
 make it On permanently.

 As I remember the decision to remove short_tags was made together with
 register_globals, magic_quotes and other legacy stuff. I can be that I
 remember wrongly, but really do people really use% ?


 Would be **really** nice if '?' with a whitespace as the next byte was
 also detected (i.e. '? ', '?\n', etc).  (Single-quotes have been added to
 aid readability.)

 The '? ' short tag is syntactic sugary convenience that is **widely**
 used:  Internal corporate servers, personal machines, and millions upon
 millions of websites.  The results and financial costs of cleaning up the
 upgrade fallout of removing the '? ' short tag are incalculable.

 Comparing short tags to magic_quotes/register_globals is apples to oranges.
  The two are so vastly different and not in the same class. The latter is a
 failed security measure.  The former is a syntactic sugary convenience.
  Every PHP userland developer I know understands the risks associated with
 magic_quotes and register_globals but, at the same time, they use the '? '
 short tag extensively wherever possible.

 Or, perhaps more simply put:  If you remove the syntactic sugary
 convenience of the '? ' short tag, you'll have an army of developers
 dropping by shortly after the release of PHP 6 and they will be incredibly
 unhappy.  But you just go ahead and remove the '? ' short tag for PHP 6.
  You'll be adding it back into PHP 6.0.1.

 The ONLY reason anyone types '?php ' in the first place is because  '? '
 isn't guaranteed to work everywhere.  And that rule really only applies to
 open source software and certain web hosts, which is a very small segment of
 the total PHP market share.  It would probably be fine if you removed the
 _option_ itself but merged '? ' detection into the core.  I don't know
 anyone who uses anything but '? ', so it won't likely be a huge loss for
 anyone if '% ' support is dropped (but I could be wrong about that).

 The important part of this discussion is making sure convenient
 functionality doesn't just vanish for stupid reasons.  I recognize there
 will be breakage regardless because it is a new major version, but looking
 ahead one extra byte isn't going to kill you.

 --
 Thomas Hruska
 CubicleSoft President

 Barebones CMS is a high-performance, open source content management system
 for web developers operating in a team environment.

 An open source CubicleSoft initiative.
 Your choice of a MIT or LGPL license.

 http://barebonescms.com/



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

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

2011-05-19 Thread dukeofgaming

On Thu, May 19, 2011 at 11:17 AM, Philip Olson phi...@roshambo.org wrote:

 
  @all
 
  Can we decide on decoupling ?= before going back to the general short
 tag
  matter?

 It feels like decoupling ?= from short_open_tag will happen. And I've not
 seen objections or reasons for not doing it, so think we can safely assume
 that it's been decided.


Awesome

[PHP-DEV] Regarding the echo short tag

Hi,

I just wanted to ask what is the community's feeling on keeping the echo
shortcut. I know short tags are kind of deprecated and I think it is the
right call, however, I really really think the echo shortcut ?= should be
kept regardless of plain short tags, which are kind of pointless. I've read
the RFC regarding this and I think the second + third option are the only
sane ones.

Regarding syntax, I do like ?:$var and would maybe also advocate for
%=$var or % $var. I think  another option could be a valid namespaced XML
notation php:var / (which is still shorter than ?php echo $var?), but
maybe this later has bigger implications that I'm too stupid right now to
realize (for better or worse).

I'm personally still using them since the benefit and enjoyment of working
them supersedes the worst case scenario, which is a global find  replace of
?= to ?php echo. I tell my coworkers to enjoy them while they still can,
however this is a luxury that can be only had with custom development, not
open-source projects due to the obvious problems with portability given that
short_open_tags is now off by default.

Best regards,

David Vega

Re: [PHP-DEV] Regarding the echo short tag

Should this go in Accepted then?.

Regards,

David

On Wed, May 18, 2011 at 1:16 PM, Ferenc Kovacs i...@tyrael.hu wrote:

 On Wednesday, May 18, 2011, dukeofgaming dukeofgam...@gmail.com wrote:
  Hi,
 
  I just wanted to ask what is the community's feeling on keeping the echo
  shortcut. I know short tags are kind of deprecated and I think it is the
  right call, however, I really really think the echo shortcut ?= should
 be
  kept regardless of plain short tags, which are kind of pointless. I've
 read
  the RFC regarding this and I think the second + third option are the only
  sane ones.
 
  Regarding syntax, I do like ?:$var and would maybe also advocate for
  %=$var or % $var. I think  another option could be a valid namespaced
 XML
  notation php:var / (which is still shorter than ?php echo $var?), but
  maybe this later has bigger implications that I'm too stupid right now to
  realize (for better or worse).
 
  I'm personally still using them since the benefit and enjoyment of
 working
  them supersedes the worst case scenario, which is a global find  replace
 of
  ?= to ?php echo. I tell my coworkers to enjoy them while they still
 can,
  however this is a luxury that can be only had with custom development,
 not
  open-source projects due to the obvious problems with portability given
 that
  short_open_tags is now off by default.
 
  Best regards,
 
  David Vega
 

 I thought we alredy decided to keep the short echo.

 Tyrael

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

Hi,

I'm that somebody Tyrael is talking about. FTR, I'm all for deprecating
short tags, but I do feel the echo shortcut is a separate issue. Perhaps if
?php= was implemented a greater deal of people on both sides of the
discussion would be happier.

Best regards,

David

On Wed, May 18, 2011 at 2:13 PM, Ferenc Kovacs tyr...@gmail.com wrote:

 On Tue, Apr 14, 2009 at 8:06 PM, Philip Olson phi...@roshambo.org wrote:

  PLEASE, let the dead horse be!
 
 
  Apparently, this horse is not as dead as some would like it to be :)
 
 
  The horse is not dead or if so then no proper burial service was given.
  People are still waiting for the invitations and wanting to hear the
 eulogy.
 
  So, instead I'll make the following assumptions and engrave them into
 this
  topics tombstone:
 
   - short_open_tag is fully alive
   - short_open_tag is PHP_INI_SYSTEM|PHP_INI_PERDIR
   - all distributed php.ini files disable it (5.3+)
   - the default will be enabled, forever, unless #5 is used
   - --disable-short-tags will exist, forever
   - no new alternative syntax will be implemented, ever
 
  That's the situation people should understand and since this horse is
  considered dead I will:
 
   - update php.ini ini descriptions to reflect this
   - update documentation to reflect this
   - mark http://wiki.php.net/rfc/shortags as declined
   - point to the declined rfc when people suggest these alternatives
 
  All discussion is over unless a human knows the above synopsis is false,
  because CVS has spoken. RIP.
 
 
 apparently somebody else brought up the shortag(specifically the ?= tag)
 topic again, and I've noticed that you moved the rfc from declined to In
 discussion recently (https://wiki.php.net/rfc/shortags?do=revisions), so
 I
 would like to know that are these rules still hold, or did something
 happened since this decision?
 I couldn't find the suggested clarification in the docs either (maybe
 looked
 at the wrong place)

 Tyrael

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

So what would be there to discuss or agree on?, now that the topic is at
hand.

Regards,

David

On Wed, May 18, 2011 at 9:05 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 Hi!


  As far as I remember there weren't any serious objections to decoupling
 ?= and leaving it always enabled. It doesn't interfere with other PI
 tags in a file, and nobody else is going to come along and use it on us.


 That's what I think too, but since there was no agreement fixed on that, I
 put it into discussion part.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227


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

Re: [PHP-DEV] annotations again

Hi,

On Wed, May 11, 2011 at 12:41 AM, Lester Caine les...@lsces.co.uk wrote:

 guilhermebla...@gmail.com wrote:

 So, please stop saying no to every feature request that comes in and
 start to discuss the actual impact of each feature.


 I think that MY only problem with you 'adding annotations because it is
 missing' is simply that I've already been doing it for years - just not
 calling it 'annotations' ... its 'documentation' and always has been ...


It is really troubling to read that statement. Seems there are still some
that don't really have a clue of what annotations are, even when the RFC
clearly links to them. Annotations ARE NOT documentation; in the case of
PHP, documentation is being used as annotations because there is no language
implementation, which exists in other languages (Java, .NET) and they are
widely used. Also, some use annotations as documentation (e.g. store the
class version), but again, annotations ARE NOT documentation. Don't let the
@ notation shared with docblock fool you.

Guilherme, I think its easy to assume that people already have some sense of
what annotations are, but perhaps the wiki entry could be more educational
about it?. The first time I read about annotations it was from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.



 The real problem at present is that the whole ecosystem is now so
 disjointed that PHP5.2 is the last version that is still fairly fully
 supported, but people are pushing for 5.4 before 5.3 has been properly put
 to bed. We need to finish of what is already added fully before pushing more
 new stuff in? That INCLUDES in the ecosystem!

 And we still have the hole that is unicode ...


This is another thing that troubles me when I read this list. How does the
PHP core dev community sets priorities?, is there some sort of roadmap?, is
there a process to create this roadmap?, or is it just all a generalized
best intention to do things.

I'm aware that the more features the more has to be maintained, but, what I
see is that there is lot of potential for the core dev community to grow and
at its current state it doesn't seem to be able scale due to the lack of a
roadmap/process.

I'm not trying to be a douche here, just saying: I see lots of criticism
towards everything and very few agreements.

Best regards,

David Vega

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 2:59 AM, Lars Schultz lars.schu...@toolpark.comwrote:

 Am 11.05.2011 09:35, schrieb dukeofgaming:

  Que?. Are you aware that you cannot implement interface methods?.

 Sorry. my bad. I mixed implementation with specification, but it would
 work, no?


Eh, well, in a weird and complex way I'd guess =P. If it were about
implementing a workaround to annotations for class metadata I'd use mixins
and magic methods, but that doesn't win over annotations, not by a long
shot.


  I really think the dilemma of whether annotations are useful or not is
 moot.

 What an argument. I'm not saying they are not useful. I am saying they can
 be done with what we already have. I've got tons of code which could run
 faster if the core-devs finally decided to take my aproach over theirs...;)

 Also citings of .NET and Java makes me wanna scream, because I don't want
 those languages. I want PHP, which has been my faithful servant for over 12
 years!


I rarely use Java, I personally hate .NET, and PHP is the language that has
been giving me my bread and butter since I started as a developer. I'm just
saying that as far as language design goes, this is not something new and it
has been succesfully taken advantage of for years.

Also, and if I'm not mistaken, PHP has already taken from Java's example
with exceptions and the interfaces you love =P.

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 2:45 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

The roadmap is in the form of a feature list which you can find at
http://wiki.php.net/etcwiki.php.net/etc
There is never going to be complete agreement on any feature, but once
there is enough agreement from the main stakeholders in a certain feature
and the implementation looks feasible both from a technical perspective and
from actually having someone willing to do the work, it gets assigned to a
release.

The link doesn't work, but I'm assuming it is this one?:
https://wiki.php.net/todo

In the case of annotations there were some serious stakeholders, like
Matthew, Sebastian and others who really do understand what annotations are
and why they are needed, but they did not agree with the proposed approach.
That's why we have the RFCs and that's why these discussions flare up around
release time. It triggers people to take a really serious look at a feature
to see how it would work for them.

In other words, the ideal situation to move this particular case forward is
to have more stakeholders join the discussion, right?. An issue that I see
here is that it is not that easy to join in the discussion because:

a) They would need to be already in the list to have an easy way to access
all the messages
b) The thread is too disperse to follow in
http://news.php.net/php.internals/
c) The public mirror of the newsgroup is faulty, see
http://news.php.net/php.internals/52242 for example

*command too long: XPATH 4dc826b1.4090...@lerdorf.com
4dc82a36.8090...@lerdorf.com 4dc83401.2090...@sugarcrm.com
4dc8d122.3050...@lsces.co.uk 4dc8f125.2010...@toolpark.com
4dc8fb1a.7040...@lerdorf.com*

My suggestion for this —and it would be a rather disruptive one, I know— is
to move the lists to Google Groups, or at least create one or two as an
experiment, say: php-userland and php-dev.

BTW, Guilherme is an important stakeholder too, he has participated in
Doctrine2 annotation-related work:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php

And yes there is a lot of noise. You will see quite a few uninformed
opinions, and a few informed ones. We have always kept things completely
open for anyone to have their say. This openness gives people access, but it
also often gives people the sense that there is complete chaos. We are not
.Net.

That I understand, respect and applaud. Still, I think a better process
would provide more transparency (openness !== transparency), which is an
issue I've seen others complain about. This way, people willing to implement
their own feature might understand easier that if they help out with
existing actionable PHP problems, the community could shift more easily
their attention to their proposals.

The way I see it, PHP has moved by inertia all these years, and it has
worked, but I think there are measures that could be taken to lead the
discussions towards a more productive path. For example, is there anyone at
all that does some kind of moderation?, and I don't mean the coercive type,
but the hey guys, this seems off-topic, can you start this discussion on
another email thread? type of moderation.

Best regards,

David Vega

Re: [PHP-DEV] 5.4 again

On Wed, May 11, 2011 at 2:52 AM, Michael Wallner m...@php.net wrote:

 On 05/10/2011 01:04 PM, Stefan Marr wrote:


 The whole thing required a lot of, what I would characterize as,
 hand-holding. Internals is not the most open community and needs not
 only good arguments, but persistence. And, well, it also seem to
 require to get in touch with the right people...

 And now the whole discussion about 5.4 goes again in a direction
 where it will probably be stalled in the end. I am not to optimistic
 about an actual release date within 2011.


 Don't lose your head on it.  If you look at the output buffering code
 contained in trunk (which is to become 5.4), you may discover that it
 has been written exactly 5 years ago.


*gasps*

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 4:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 05/11/2011 01:39 AM, dukeofgaming wrote:

 The link doesn't work, but I'm assuming it is this one?:
 https://wiki.php.net/todo


 That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up)


I see. I have actually read most RFCs, but I do feel something is meesing.
Perhaps if RFCs were categorized by potential release in the wiki —or
alternatively, an additional Intented PHP version field— then agreements
coud get easier, because I don't see consistent PHP version information for
RFCs that could lead to an actual roadmap.


 I don't think we need to lower the participation bar further here. It
 doesn't take very long to find a threaded version of the list if that is
 what you think is holding people back. All the lists are here,
 http://php.markmail.org/search/ for example.


 But honestly, subscribing to a mailing list and watching it for a while
 before participating is not too much to ask from people who want to
 participate.


  My suggestion for this —and it would be a rather disruptive one, I know—
 is to move the lists to Google Groups, or at least create one or two as
 an experiment, say: php-userland and php-dev.


 We have such a user list already. Many of them actually, but the main one
 is php-general. Again, refer to the above link where you can see that
 php-general gets way more traffic than the internals list, so there is no
 lack of participation there.


I wholeheartedly agree, but sometimes it is the small details that lead
to dissuasion (e.g. having to look for the right/best mirror). In general
I've found Google Groups mailing lists more approachable/usable. I see now
that there are nice mirrors, but in general the mirror solution feels
fragmented. Just my opinion here.



  BTW, Guilherme is an important stakeholder too, he has participated in
 Doctrine2 annotation-related work:


 Of course he is. But like I said, we need all the major stakeholders to
 reach some sort of agreement on large efforts like this.


How could we get them here?. I know there is no magical answer but if we do
need them here something must be done, right? (e.g. make the RFC more
appealing for technical debate?).




  The way I see it, PHP has moved by inertia all these years, and it has
 worked, but I think there are measures that could be taken to lead the
 discussions towards a more productive path. For example, is there anyone
 at all that does some kind of moderation?, and I don't mean the coercive
 type, but the hey guys, this seems off-topic, can you start this
 discussion on another email thread? type of moderation.


 Of course. I've often sent private emails to people to politely suggest
 they take things offline and others regularly step in as well.


But, is there such a role/responsibility/structure within the community?,
and  I'm really not talking about hierarchy or bureaucracy, just that I've
seen it is important that there is someone that commits to such a role and
not just leave it to other's good will.

Best regards,

David

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 11:59 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:


 My main concern is the trickle-down effect a major low-level engine
 addition causes. Your patch is just the tip of the iceberg which will cause
 dozens of people weeks of work to account for the new code all across the
 PHP ecosystem. The most complicated being the opcode cache support which
 really only can be written by a handful of people due to the complexity
 involved. Combine that with the fact that other projects who currently use
 annotations, perhaps not to the level of Doctrine, but still, state that
 they would have a hard time switching to this new approach it becomes really
 hard to commit all these people and all this time to this.

 We are severely resource-constrained when it comes to people who can write
 solid low-level C code and we have to be very careful what we ask our
 volunteers to spend their time on. A volunteer developer who isn't excited
 about a feature is going to drag her feet and it will sit solidly at the
 bottom of the priority list for months, if not years. If a key piece of the
 eco-system isn't updated because of this one addition, it means that
 potential PHP 5.4 users may have to wait 6, 12, 18 months before they can
 migrate to the new version.

 Therefore, low-level engine changes, syntax additions, or entirely new
 grammars as is the case here, face an uphill battle. If there is a way to
 currently solve the problem without major changes, even if it is an 80%
 solution that will weigh heavily against accepting the new code.

 Without broad support and enthusiasm, especially from the people who have
 historically been the ones that write the code and track down and fix the
 bugs, low-level features like this are doomed, no matter how
 well-intentioned they are.


That explanation sheds a lot of light on the general situation, thanks.

Something I wanted to ask —regarding resources— is, is GSOC being leveraged
this year in any way?. I'm guessing there could be lots of enthusiasm packed
there, perhanos not that much for C writing, but for clearing the way for C
writers.

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 12:29 PM, guilhermebla...@gmail.com 
guilhermebla...@gmail.com wrote:

 Hi Larz,

 On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schu...@toolpark.com
 wrote:
  Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com:
 
  - Entities with knowledge about its persistence information
 
  That must be something I simply have no knowledge about. But isn't it
 just a
  theoretical difference, because in practice, the code being annotations
 or
  PHP-Code is kept within the class, therefore the entity is not separated
  from its persistence information...but then I don't really understand the
  problem in the first place;)
 

 I hope you have OO architecture knowledge.
 By having entity implementing an interface/abstract class, you make
 your domain classes depending on persistence package.
 This dependency breaks OO encapsulation of packages.

 By having the code (annotations) within the class you just meta
 classify each property/method of your class.
 You probably don't know, but annotations that you use in Doctrine
 follows a standard document usually referred as JPA (or JSR-317),
 second version.
 So, you may be surprised, but any persistence tool that follows this
 document would be able to support this Entity. One good example is how
 ORM package of Doctrine works and you're able to have your Entity
 schemaless with almost 0 changes in ODM package (read as CouchDB and
 MongoDB).


I think part of the problem on the discussion —regarding the acceptance of
the feature— is that annotations are being seen just as a cute feature,
instead of an architectural advantage to all good PHP code (i.e. OO taking
advantage of design patterns) and its implications. In summary: they are
huge. If simple reflection can tell the developers what the code is,
annotations let them know what it can be in depending on their context (i.e.
behavior is decoupled).


  - Resources being wasted
 
  Now you sound like Rasmus when he talks about his assembly-history. Do
 you
  really expect Annotations to perform better than hard-wired php-code?
 

 Yes, and built-in support is WAY faster.


If I'm not mistaken, the current comment-parsing solutions are so slow that
the annotated classes and methods and attributes *NEED* the metadata to be
cached in separate PHP code in order to function, otherwise it would be
practically impossible to use them in production sites; conversely, if they
were supported natively caching would not be absolutely necessary. Is this
the case?, if so, I think it is a strong use case to be considered for the
RFC.

BTW, why is it rejected in the wiki now?. Is it completely completely
rejected?, or just postponed?... if it is just cataloged as declined for
now, perhaps it will be harder to retake for discussion later if it appears
as declined?.

Re: [PHP-DEV] annotations again

On Wed, May 11, 2011 at 4:57 PM, guilhermebla...@gmail.com 
guilhermebla...@gmail.com wrote:

 Hi duke,

 I moved it to rejected in pro of a new proposal.
 I briefly drafted it here:
 https://wiki.php.net/rfc/annotations-in-docblock

 There's a lot of things to be officially defined, but basic idea is there.
 I expect to have a chat with interested core devs to see what can be
 done in this subject and find some common sense. =)


Ok, so the agreed direction now would be to have some initial support for
annotations in comments to achieve syntax and data uniformity, and after its
necessity/utility is obvious to everybody then we can move to native
support?. Is this correct?.

BTW, I love the idea of using JSON as value.

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread dukeofgaming



 so the problem is, that the userland is under-represented in the
 development, because they usually not present on the mailing list and on
 irc, where discussions and decisions happen, and they usually have
 different
 priorities and expectations about the PHP language than the core devs.
 to make things worse, they cannot write patches for the core, and the core
 devs rarely work on something which they don't particularly need or like.

 and I think that the only option where we can change that, is that us, the
 php userland devs has to be more active on the mailing lists, irc, bug
 tracking, writing RFCs etc.


Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.

Regards,

David Vega

Re: [PHP-DEV] 5.4 again

2011-05-10 Thread dukeofgaming

On Tue, May 10, 2011 at 2:42 PM, Ferenc Kovacs i...@tyrael.hu wrote:



 On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgam...@gmail.comwrote:


 so the problem is, that the userland is under-represented in the
 development, because they usually not present on the mailing list and on
 irc, where discussions and decisions happen, and they usually have
 different
 priorities and expectations about the PHP language than the core devs.
 to make things worse, they cannot write patches for the core, and the
 core
 devs rarely work on something which they don't particularly need or like.

 and I think that the only option where we can change that, is that us,
 the
 php userland devs has to be more active on the mailing lists, irc, bug
 tracking, writing RFCs etc.


 Why not open a Google Groups list?, having every message recorded publicly
 and being easy to join-in I'd bet that the situation would change. I've seen
 it work really well for other open source projects, such as Joomla and
 Symfony.


 you can already do that through http://marc.info/?l=php-internals or the
 newsgroup, see http://php.net/mailing-lists.php
 albeit google groups is better imho

 Tyrael


Yeah, I forgot to mention that everything is threaded there, so its easier
to follow.

Regards,

David Vega

Re: [PHP-DEV] 5.4 again

2011-05-09 Thread dukeofgaming

On Mon, May 9, 2011 at 12:44 PM, Ferenc Kovacs i...@tyrael.hu wrote:

That's simply not true. But just because one group of users feel
strongly
about something doesn't mean it should go in. There has to be some
level
of
curation or we end up with every feature under the sun resulting in a
huge
mess.

Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.

there is at least one, mine

but I also think that the core devs and the php userland/community is too
far away, we would need more people from the userland to contribute to the
development of the php language.

http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6

http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
“Because
it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm
isn’t strong.” — @coates
“Those with talent, competence, energy,and good ideas over a period of time
- and who outlast the rest - tend to be the main drivers behind
PHPdevelopment.” — @a

Tyrael

Hi,

After having some experience participating in other open-source communities,
specially Joomla (but also Mootools, Doctrine and Symfony), my first
impression when subscribing and reading this list was: wow, its hostile,
and I automatically refrained from wanting to participate and chose just to
observe for the meantime.

I know every community is different, but, even if a single person states
something that might look like a problem it is an indicator that you might
have it.

I think the PHP community could benefit from a process like Python's PEP
Workflow: http://www.python.org/dev/peps/pep-0001/#pep-work-flow.

Personal attacks achieve nothing, and contributing to open-source is MORE
than contributing code, and even if you do contribute, it doesn't look like
it is even an automatic way to get the needed attention. I've seen Guilherme
post several times asking for feedback (i.e. building upon his work, not
just criticizing him) and I have never seen it. I don't think Guilherme
loves spending his afternoons advancing in a patch without the slightest
sense of community direction.

Being brutally honest, looks to me that this generalized attitude/culture
might actually be scaring willing devs away, and the community itself needs
some kind of direction. Here is a recommended watch:

O'Reilly MySQL CE 2010: Jono Bacon, The Engines Of Community:
http://blip.tv/file/3495291

Best regards,

David

Re: [PHP-DEV] DVCS

2011-04-27 Thread dukeofgaming

Hi,

I'm not a frequent poster in the list but I thought I'd really should give
my 1 cent here when I saw popular being an argument for using DVCSs, its
not, and its neither fashion nor cargo cult, it is just a plain eye opener
experience of how neither SVN or CVS are the base of all versioning (two of
its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged
this by saying sorry about that with regards to Subversion) and that
better and more natural ways to collaborate and integrate code.

I could provide an epically long argument here, but instead I'll link to the
one I've already made, diagrams and graphics included =):

http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080

So, I don't want to make debate here of wether centralized is better than
distributed (because the point is moot), but I think its not a good
situation for the community to have a previously open door to DVCSs now
closed.

Perhaps a solution can be found to even open the door to Mercurial (that is
an excellent place to start with DVCSs because its simplicity and
straight-forwardness) in addition to git in such a way that doesn't stress
the server?.

Regards,

David

On Wed, Apr 27, 2011 at 9:40 PM, Drak d...@zikula.org wrote:

On 28 April 2011 07:55, Ben Schmidt mail_ben_schm...@yahoo.com.au wrote:

I realise that at least for now, PHP is sticking with SVN. No problems.

I realise this is not the topic of discussion but I have to say, that
overall, a switch to DVCS would make a huge difference to PHP development
life cycles. Git for one, makes contributing and integration of patches a
completely different experience. It encourages more community
participation
without impinging on quality since you don't need to grant commit
permissions. The whole workflow of creating and integrating patches is
much
faster and more simple because you can switch context from branch to branch
almost instantly allowing those with commit permissions to verify if a
contribution is worth merging or not. It's much less work than SVN and the
ease naturally attracts contributors. Merging is not a pita like with SVN.

However, given the recent security breach there is another side: Tampering
with a git repository is virtually impossible because every commit hash is
generated from the previous ones, so if your servers were compromised
again,
a change in the past history would require alteration every single commit
hash since that change and the resulting HEAD hash would be different.
Since hashes are based on the commit contents it's just not feasible even
if SHA1 was one day compromised that you could successfully tamper with a
previous commit and engineer the calculations so the current HEAD hash
remained unchanged. If a commit blob (on the file-system) was altered
manually, your git repo would simply fail to validate the next time you use
it. In every scenario you'd know immediately something was wrong and not
have to go looking for it commit by commit.

Something to consider again in the future at least.

Regards,

Drak

Re: [PHP-DEV] DVCS

2011-04-27 Thread dukeofgaming

Hi Ben, I'm sorry I did a wrong remark there, but I see you saw what I
meant.

The nice thing about open source projects is that communities develop
naturally around them, it becomes an ecosystem, everything tends to lean
towards balance, when a change is intended to be made it should be allowed
to develop organically. Point here is: lets not try to force DVCSs but
rather keep the door open so the community can pass through it whenever it
feels ready, so the dilema of current devs vs potential devs never happens.

My advice here is —if current devs are willing— to pilot test a DVCS on a
small part of the project where it can be used primarily (as in not with
subversion); this would be a very healthy exercise to understand the why of
this generalized DVCS-ish concern. Another advice is to open the discussion
towards the choice of a DVCS in comparison to the project's interests and
demographics (e.g. if there are more windows users than mac/linux, mercurial
would be preferred, if its the other way around there is an underlying
git community, git might be best).

To all who doubt DVCS, this is a good read for you:
http://hginit.com/00.html

In relation to Drak's remarks, yes, I think the maturity of the tools has
contributed to its increased usage, and also, the very cool services around
them, such as github.com and bitbucket.org.

Finally, I think from here on, the conversation should be focused on finding
a technical solution to the load problem (I'm not familiar with the setup,
but if I think of something I'll post it).

Regards,

David

On Wed, Apr 27, 2011 at 10:29 PM, Ben Schmidt mail_ben_schm...@yahoo.com.au
wrote:

Just for the recordI didn't say popularity was a reason to use a DVCS.
I said the popularity of DVCSes might cause server strain (if a lot of
people want to convert the public SVN repo to a distributed one, downloading
all the changes in the repo, which SVN really wasn't designed for, that
would be a heavy load--and positively correlated to popularity: more
popular, more conversions, more load).

I agree with your closing point, though: I'd love to see us look for a
low-load way of providing an Hg mirror and/or a Git mirror. I also think
that either a mirror or a change of VCS may attract developers in the
medium-term. However, I also think that current developers carry a lot more
weight than potential developers, and it's important for them to be able to
work in a way that is comfortable for them. So a mirror or two would be
nice, and I'd push for that, but a change of official repo I will merely
suggest be considered longer term.

Ben.

On 28/04/11 1:07 PM, dukeofgaming wrote:

Hi,

I'm not a frequent poster in the list but I thought I'd really should give
my 1 cent here when I saw popular being an argument for using DVCSs, its
not, and its neither fashion nor cargo cult, it is just a plain eye opener
experience of how neither SVN or CVS are the base of all versioning (two
of
its creators —Brian Fitzpatrick and Ben Collins-Sussman— have acknowledged
this by saying sorry about that with regards to Subversion) and that
better and more natural ways to collaborate and integrate code.

I could provide an epically long argument here, but instead I'll link to
the
one I've already made, diagrams and graphics included =):

http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080

Perhaps a solution can be found to even open the door to Mercurial (that
is
an excellent place to start with DVCSs because its simplicity and
straight-forwardness) in addition to git in such a way that doesn't stress
the server?.

Regards,

David

On Wed, Apr 27, 2011 at 9:40 PM, Drakd...@zikula.org wrote:

On 28 April 2011 07:55, Ben Schmidtmail_ben_schm...@yahoo.com.au
wrote:

I realise that at least for now, PHP is sticking with SVN. No problems.

I realise this is not the topic of discussion but I have to say, that
overall, a switch to DVCS would make a huge difference to PHP development
life cycles. Git for one, makes contributing and integration of patches
a
completely different experience. It encourages more community
participation
without impinging on quality since you don't need to grant commit
permissions. The whole workflow of creating and integrating patches is
much
faster and more simple because you can switch context from branch to
branch
almost instantly allowing those with commit permissions to verify if a
contribution is worth merging or not. It's much less work than SVN and
the
ease naturally attracts contributors. Merging is not a pita like with
SVN.

However, given the recent security breach there is another side

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

2011-04-08 Thread dukeofgaming

Hi, just to drop an opinion on something I felt natural when reading this:
how about a word instead?:

$value = 'Not set' unless $a['key'];

I think it would be way more readable.

Regards,

David

On Fri, Apr 8, 2011 at 2:02 AM, Adam Richardson simples...@gmail.comwrote:

 
 
   We need to be careful about changing the beahviour of existing
  operators.
 

 Indeed.

 The '?' character already is special, so using '??' seems like a safe,
 practical approach. However, I'd prefer maintaining the form of the
 standard
 ternary operator with the colon ($value = $var['bar'] ?? : 'Bar was not
 set'; // value =Bar was not) so the '??' operator could be applied in any
 situation that one would normally use the standard ternary operator.

 // standard
 $value = isset($a[$key]) ? $a[$key] : 'Not set';

 // new ?? double ternary that performs isset check and omits second
 expression
 $value = $a[$key] ?? : 'Not set';

 // new ?? double ternary that performs isset check and uses second
 expression
 $value = $a[$key] ?? strtoupper($a[$key]) : 'Not set';

 Granted, the last example might be infrequent, but I think there's also a
 value in keeping the form of the double ternary (if used at all) the same
 as
 the standard ternary operator for consistency sake.

 Adam

 --
 Nephtali:  A simple, flexible, fast, and security-focused PHP framework
 http://nephtaliproject.com

Re: [PHP-DEV] git anyone?

Yet another one here: http://hginit.com/00.html

http://hginit.com/00.htmlThe title says it all: Subversion re-education.
It is actualyy a somewhat neutral article even though the page is a
mercurial tutorial.

Regards,

David

http://hginit.com/00.html

On Thu, Dec 2, 2010 at 12:44 AM, Larry Garfield la...@garfieldtech.comwrote:

 The Drupal project's decision making process for moving to Git is
 documented
 extensively here:

 http://groups.drupal.org/node/48818

 Just another data point.

 --Larry Garfield

 On Wednesday, December 01, 2010 2:52:53 pm dukeofgaming wrote:
  Hi,
 
  I was following this path to push the adoption of a DVCS for the Joomla
  project and I started to create the required documentation to make an
  informed argument and evaluation, I made some diagrams to make the case
 for
  their need for good team development and workflows, feel free to borrow
 any
  content/diagrams from here http://docs.joomla.org/Dvcs
 
  If an RFC is started I'd love to help. I have experience with git and
  mercurial.
 
  http://docs.joomla.org/DvcsRegards,
 
  David

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

Re: [PHP-DEV] git anyone?

Its actually faster to use the command line when u have enough practice;
picture yourself merging branches or something more complicated, I think its
easier typing stuff as you think it than finding your way around a GUI,
command line reacts faster than a GUI too. I use the IDE integration though,
but not the shell integration, at all. I agree on visualizing repository
tree on the GUI though. In the end its up to each individual.

Regards,

David

On Thu, Dec 2, 2010 at 3:12 AM, Lester Caine les...@lsces.co.uk wrote:

 dukeofgaming wrote:

 Yet another one here:http://hginit.com/00.html

 http://hginit.com/00.htmlThe title says it all: Subversion
 re-education.
 It is actualyy a somewhat neutral article even though the page is a
 mercurial tutorial.


 Actually this probably point up one of the fundamental differences between
 the different ways of working.

 'Most people work with Mercurial through the command line'
 ... fill in your own package ...

 Personally I very rairly use any of these from the command line, since
 Eclipse has fully integrated facilities. The statement 'it just works from
 the cammand line' only applies if that is what you are still using, but even
 CVS I would have to dig out the manual to use the command line.

 Productivity wise, having to pull out of the IDE to do code management is
 the main problem with switching from CVS/SVN to any of the alternatives, but
 the main thing I can't understand is how people actually MANAGE with command
 line when dealing with a large number of changes? A graphical facility is
 almost essential when navigating around complex code trees and viewing diffs
 which are more than a few dozen lines?

 ( Pierre this is probably one of the reasons I had so much trouble building
 PHP on windows ... simply because I have used graphic IDE's since C++
 Builder 1 days and before :( Command line working is a somewhat different
 mind set ... and prior to C++ I was working on hand coded machine code ... )

 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk//
 Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

I toast to that. Get rid of T_VAR already.

Regards,

David

On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:

 2010/11/30 Kalle Sommer Nielsen ka...@php.net:
  Hi
 
  2010/11/30 Patrick ALLAERT patrickalla...@php.net:
  With this patch, something looks inconsistent to me:
  Both properties and methods have a visibility
  (public|protected|private) and a keyword: var (T_VAR) and function
  (T_FUNCTION) respectively.
  However private var $foo; generates a fatal error but private
  function foo(){} not?
 
  The var keyword is an alias of the public keyword for BC with
  PHP4. So it would be illogically to declare a property both private
  and public at the same time ;-)

 Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
 introducing the possible omission of T_FUNCTION?

 Patrick

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

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

How about deprecation then?

On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke a...@ez.no wrote:

 On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
 wrote:

  2010/11/30 Kalle Sommer Nielsen ka...@php.net:
   Hi
  
   2010/11/30 Patrick ALLAERT patrickalla...@php.net:
   With this patch, something looks inconsistent to me:
   Both properties and methods have a visibility
   (public|protected|private) and a keyword: var (T_VAR) and function
   (T_FUNCTION) respectively.
   However private var $foo; generates a fatal error but private
   function foo(){} not?
  
   The var keyword is an alias of the public keyword for BC with
   PHP4. So it would be illogically to declare a property both private
   and public at the same time ;-)
 
  Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
  introducing the possible omission of T_FUNCTION?


 Why?

 This will break lots of code, does it improve anything while at it? Is
 'var'
 hindering anything? Is it taking up a lot of code?
 If it is removed then that should be in trunk aka 6.0 the 2nd , and not
 in
 5.x.

Re: [PHP-DEV] git anyone?