Hi!
> I very much disagree, engine details should not be visible to users.
> It is irrelevant to them and only serves to confuse.
It's not engine detail. We're not talking about exposing C pointers or
zend_op values. We're talking about implementing methods that have
special meaning. They are still methods and it only makes sense that
they behave like other methods do. Not doing that - as you are perfectly
aware - adds a lot of complications and makes the engine inconsistent -
now you have methods that engine treats one way and methods that the
engine teats in completely different way, and in every place you deal
with methods you need to have special cases.
> To be clear, they would be regular methods, they would just not exist
> in the HashTable *functions of the class. In every other way they
> are methods of the class.
Don't sound like a good idea. Imagine a debugger/profiler that works
with PHP. Now instead of having one hashtable to deal with it has two
since current function may or may not be in different hashtable. Imagine
extension or other tool or just engine part that deals with functions -
now everywhere you have to make provisions for the fact that functions
now live in two places instead of one. I don't think design-wise it is a
good idea.
> See the problem?
I am *NOT* saiyng you should apply isset operator as it to it. I am
saying that code that is implementing the default isset should work
*exactly* as the isset operator would work on regular property. Of
course it can not be the same operator - it should be changed/extended -
but it should keep working the same way. E.g. not return "not set" when
property is set to 0.
> I don't know the other "contexts" that need to be tested. There are
> already over 80 tests written for this (.phpt) that all pass, please
> let me know what other tests need to be written and I'd be happy to
> write them.
I think the following cases should be covered:
- $foo->bar++/-- (postfix and prefix) - with actual value being number,
string, empty, not existing.
- $foo->bar[$index] = $x (with value being array, object with
ArrayAccess, string, integer - the last should produce proper error and
no leaks)
- $foo->bar[] = $x with the same as above
- $foo->bar->baz = $x with $bar being object or empty or non-object
value (proper error and no leaks)
- $foo->bar{$x} = "foo" (string offsets), also checks that non-string
vars work fine
- $foo->bar =& $bar->baz, etc. with modifying both sides and checking
everything works (including modifying via accessors)
- property loop detection needs to be tested (i.e. $this->foo in getter
for $foo or $this->bar in $foo and $this->foo in $bar).
Maybe more if I'd think of anything.
I realize some of these may feel obvious but we're modifying very core
part - it's better to be safe than sorry.
> It's preserved in the same exact way (and by the same exact code)
> that any other function over-rides are handled. The accessor syntax,
> LITERALLY, translates into functions and thus go through the ordinary
> LSP preservation lines of code. It's the reason I chose to go that
> route in the first place (to leverage the existing LSP checks)
The accessor syntax translates to functions but public $foo does not.
That's the issue. There's no existing check for overriding public $foo
with private accessor. There are checks that would work between two
accessors - but not between accessor and plain property.
> With isset/unset accessors, they *can be* implemented appropriately,
> with automatic isset/unset implementations, they cannot, for reasons
> stated above:
>
> php > isset(a());
>
> Fatal error: Can't use function return value in write context in php
> shell code on line 1
You do not need to apply isset() as is to function call. You can have
isset method that is smart enough to do the right thing. You're writing
the engine patch, not the PHP code transformation tool, so you can do
more things here. If you need specific, I can look into the code,
probably later as I'll have to move on pretty soon :)
> You've got that right... isset() cannot exist (and is not allowed) if
isset() should always be allowed - it just should return false if
something goes wrong. This is how it is used now - as safe operator
which will always work and return false if something is wrong. Making
isset() "not allowed" means that you need another operator saying "am I
allowed to call isset() here or will my code fail?". No need for that as
isset() is exactly such kind of operator for read access. No such thing
for write access btw which is quite bad since nothing now guarantees
simple $foo->bar = 1; wouldn't blow up and there's no way to check for
that. Which makes impossible to write robust code. This alone makes me
very uneasy about the whole read-only idea.
> Yes, these cases were not considered. The static accessors portion
> of this project took up an inordinate amount of time as compared to
> the rest.
Maybe we should limit accessors to dynamic ones for now or split it out
to additional spec/1.1 feature?
> But what is the value of it? The developer is working within the
> context of an accessor, not an implementation detail which doesn't
> mean anything to them?
If it doesn't mean anything, he can ignore it. However, if it *does*
mean something to him (e.g. he wants to profile/test/debug his code, or
he wants to do some other thing where current function is important) it
should be consistent. I'm very much against introducing inconsistencies
in the engine when it is not warranted by very good reasons.
> In this regard, I have yet to see any proposal that is as clear or
> concise as public read-only $abc. What is the big problem with
> adding read-only and write-only keywords? Once they are in the
> language they could be expanded to plain properties.
I think special-case keywords are usually not a good idea unless they
cover a very frequent use case and save a lot of boilerplate code - why
a very rare case of write-only variable gets a keyword and my favorite
case doesn't? In any case, for the reasons described above I think
read-only is not a very good idea as such and we should not encourage
people to do it with special keyword unless we have a way to handle 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
