Hi:
On 01 Dec 2010, at 01:31, presid...@basnetworks.net wrote:
>>> That is true for PHP variables. isset is basically saying "does this
>>> variable exist", and unset is saying to get rid of it.
>>
>> This is also true for object properties - see magic methods. I don't see
>> why you shouldn't
While a little off topic, I feel that it is worth our having a discussion on
project management. Source control, and the like ...
Current discussion on 'git' highlights the fact that there is no clear solution
to source control. The switch TO SVN was pushed through even though a few
problems w
On Tue, 2010-11-30 at 19:31 -0500, presid...@basnetworks.net wrote:
>
> isset() in the way you suggest would just be confusing. It would
> allow is
> to say that a property does not exist, when in fact it does exist.
> This
> is not logical.
Even when a property does exist physically (by these
On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine wrote:
> While a little off topic, I feel that it is worth our having a discussion
> on project management. Source control, and the like ...
>
I agree.
>
> Current discussion on 'git' highlights the fact that there is no clear
> solution to source c
On Wed, Dec 1, 2010 at 1:12 AM, Lester Caine wrote:
> While a little off topic, I feel that it is worth our having a discussion
> on project management. Source control, and the like ...
>
> Current discussion on 'git' highlights the fact that there is no clear
> solution to source control. The sw
Hi!
Its not a matter of consistency - Properties, as a cross-language concept
are not meant to work that way. You need to think of a property as a set
Meant by whom? Is there some law of universe that prevents us from
implementing the feature?
of two methods that just have a pretty syntax
Hi!
Just to chime in on the subject of performance, here is how C# handles
properties:
PHP is not a compiled language and as such handling of properties, in
particular, is radically different in PHP. For example, the property
name in expression like $foo->$bar is known only in runtime.
--
On 1 December 2010 09:22, Stas Malyshev wrote:
> Hi!
>
>> Its not a matter of consistency - Properties, as a cross-language concept
>> are not meant to work that way. You need to think of a property as a set
>
> Meant by whom? Is there some law of universe that prevents us from
> implementing the
See other post as well
Nathan Nobbe wrote:
git archive cranks out a single file representing any commit in the
repository, it can even format the archive w/ zip for the windows folks ;)
YES but without any header updates to the files.
Once unzipped you have no idea what version a file is, and
2010/12/1 Eloy Bote Falcon
> 2010/12/1 Richard Quadling
>
> On 1 December 2010 09:22, Stas Malyshev wrote:
>> > Hi!
>> >
>> >> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> >> are not meant to work that way. You need to think of a property as a
>> set
>> >
>>
Hi!
If we think of properties as this new entity for the language (rather
than somehow massaging existing entities to fit a new usage scenario),
then
I think the idea of new entity of the language looking exactly like old
entity of the language but having different rules is kind of non-starte
Hi Richard:
On 01 Dec 2010, at 10:57, Richard Quadling wrote:
> If we think of properties as this new entity for the language (rather
> than somehow massaging existing entities to fit a new usage scenario),
> then
>
> isset($instance->property) will always return true for any defined
> property.
Ferenc Kovacs wrote:
On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine mailto:les...@lsces.co.uk>> wrote:
While a little off topic, I feel that it is worth our having a
discussion on project management. Source control, and the like ...
I agree.
Current discussion on 'git' highlights the
On 01/12/10 10:13, Lester Caine wrote:
> See other post as well
>
> Nathan Nobbe wrote:
>
>> git archive cranks out a single file representing any commit in the
>> repository, it can even format the archive w/ zip for the windows
>> folks ;)
> YES but without any header updates to the files.
> Onc
On 1 December 2010 10:23, Eloy Bote Falcon wrote:
> 2010/12/1 Richard Quadling
>>
>> On 1 December 2010 09:22, Stas Malyshev wrote:
>> > Hi!
>> >
>> >> Its not a matter of consistency - Properties, as a cross-language
>> >> concept
>> >> are not meant to work that way. You need to think of a pr
On 1 December 2010 10:38, Stas Malyshev wrote:
> So we have one set of properties where get and isset use different methods
> and another set of properties where get and isset use same method but with
> parameter. I think it's not the best way to go. It's better to ignore isset
> altogether than t
Dave Ingram wrote:
git archive cranks out a single file representing any commit in the
repository, it can even format the archive w/ zip for the windows
folks ;)
YES but without any header updates to the files.
Once unzipped you have no idea what version a file is, and that IS
causing problems i
Hi!
No. The prototype of all setters would be the same. As would the
prototype of all getters.
But we'd have two sets of properties - one handled by __get/__isset,
another - by get($isset). Not a good idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)45
On 1 December 2010 12:30, Stas Malyshev wrote:
> Hi!
>
>> No. The prototype of all setters would be the same. As would the
>> prototype of all getters.
>
> But we'd have two sets of properties - one handled by __get/__isset, another
> - by get($isset). Not a good idea.
So, should properties isset
Hi Davey,
> Object properties (or members, classic ->var, not this proposed syntax)
> CURRENTLY, work this way:
>
> php -r 'class foo { public $bar; } $foo = new foo();
> var_dump(isset($foo->bar));'
> bool(false)
>
> This is because you are confusing PHP's isset() with a property_exists().
> Is s
That is true for PHP variables. isset is basically saying "does this
variable exist", and unset is saying to get rid of it.
>>>
>>> This is also true for object properties - see magic methods. I don't
>>> see
>>> why you shouldn't be able to unset them - you can do that with regular
>>>
>> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> are not meant to work that way. You need to think of a property as a
>> set
>
> Meant by whom? Is there some law of universe that prevents us from
> implementing the feature?
Its a defacto standard. Of course ther
>> Just to chime in on the subject of performance, here is how C# handles
>> properties:
>
> PHP is not a compiled language and as such handling of properties, in
> particular, is radically different in PHP. For example, the property
> name in expression like $foo->$bar is known only in runtime.
Y
public property Hours read getHours write setHours;
>>>
>>> I actually like that, though I think we should support the whole
>>> existing semantics, i.e. get/set/isset/unset. And probably keep the
>>> names, so we don't call the same thing both "read" and "get".
>>
>> This doesn't make s
Hi!
the rest of the industry, it is very confusing for programmers coming from
other languages to learn PHP. A good example is how "==" works
differently in PHP than in other languages. In PHP, "===" works like "=="
does everywhere else. "(string)'0' == (int)0", for example is true in
Not e
On 12/01/10 12:21, Lester Caine wrote:
> Dave Ingram wrote:
git archive cranks out a single file representing any commit in the
repository, it can even format the archive w/ zip for the windows
folks ;)
>>> YES but without any header updates to the files.
>>> Once unzipped you have
On 01 Dec 2010, at 14:10, presid...@basnetworks.net wrote:
> Unfortunately I find that to be one of the major downfalls of PHP. It
> sometimes disregards defacto standards that are set across the entire
> industry, which causes a lot of frustration for new programmers.
> Sometimes the functional
Hello,
> You are missing the point in PHP in that case. Because PHP is dynamic
> scripting language, public properties can be added and removed in the
> object on the fly. That's why there is isset and unset that works on
> object properties. Consider ActiveRecord, DataMappers, ORM, etc. They
> u
presid...@basnetworks.net wrote:
Its a defacto standard. Of course there is nothing stopping PHP from
implementing properties that way, but by going against the standard set by
the rest of the industry, it is very confusing for programmers coming from
other languages to learn PHP. A good exampl
hi,
I think we have enough feedback about this topic. We will come back
with a detailed proposal explaining how it could be done, which tools,
etc.
Thanks for the constructive replies,
Cheers,
On Tue, Nov 30, 2010 at 9:41 PM, dukeofgaming wrote:
> Hi, I've never participated on the lists, but
Hi Larry,
>>> First of all, I have generally found the Bean-style getter/setter
>> approach to
>>> be a sign of poor encapsulation to begin with. You shouldn't be
>>> mucking
>> with
>>> internal elements of an object in the first place, period. More
>>> details on
>>> that here:
>>>
>>> http://
Hi Larry,
>> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> are not meant to work that way. You need to think of a property as a
>> set
>> of two methods that just have a pretty syntax. Methods cannot be unset,
>> and nor should properties be allowed to. isset(
On 2010-12-01, Pierre Joye wrote:
> hi,
>
> I think we have enough feedback about this topic. We will come back
> with a detailed proposal explaining how it could be done, which tools,
> etc.
I think it would be good to have people willing to help out with evaluating
certain DVCS. In particular w
On Sun, 28 Nov 2010, presid...@basnetworks.net wrote:
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
-1
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote:
> On 2010-12-01, Pierre Joye wrote:
> > hi,
> >
> > I think we have enough feedback about this topic. We will come back
> > with a detailed proposal explaining how it could be done, which tools,
> > etc.
>
> I think it would be good to h
On 01.12.2010 16:16, Johannes Schlüter wrote:
> On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote:
>> On 2010-12-01, Pierre Joye wrote:
>>> hi,
>>>
>>> I think we have enough feedback about this topic. We will come back
>>> with a detailed proposal explaining how it could be done, which t
On 2010-12-01, Arvids Godjuks wrote:
> You are missing the point in PHP in that case. Because PHP is dynamic
> scripting language, public properties can be added and removed in the
> object on the fly. That's why there is isset and unset that works on
> object properties. Consider ActiveRecord, D
On Dec 1, 2010, at 5:16 PM, Johannes Schlüter wrote:
> On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote:
>> On 2010-12-01, Pierre Joye wrote:
>>> hi,
>>>
>>> I think we have enough feedback about this topic. We will come back
>>> with a detailed proposal explaining how it could be done
thanks for remember me the obvious questions, anything else to add or?
2010/12/1 Johannes Schlüter :
> On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote:
>> On 2010-12-01, Pierre Joye wrote:
>> > hi,
>> >
>> > I think we have enough feedback about this topic. We will come back
>> > with
presid...@basnetworks.net wrote:
> I feel that the downfall of this syntax, is that the get and set methods
> can easily be scattered at either end of a class definition. With the
> syntaxes I provided, it is easy to tell which of the methods a property
> has defined at a quick glance, because eve
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
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
On Wednesday, December 01, 2010 8:28:19 am presid...@basnetworks.net wrote:
> > Is this consistent with methods? Do those share a namespace, too? (I
> > don't actually recall off the top of my head.)
>
> methods and variables have their own namespaces. This is because they are
> called differe
On Wednesday, December 01, 2010 8:47:50 am presid...@basnetworks.net wrote:
> > Actually, I can even think of a concrete use case. Suppose I have an
> > object that acts as a facade for a remote object over SOAP, REST, or
> > whatever. It is using properties to represent attributes of a remote,
44 matches
Mail list logo
