On 4/18/16 2:24 PM, Stanislav Malyshev wrote:
I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entrance barrier and b) is in
production use by millions and has 20 years of existing practices,
libraries and habits, we have to be a bit more wary, I think. I am *not*
saying we should not improve, or ignore academic developments, I am
saying that we should be careful with not jumping to the idea-of-the-day
bandwagon too fast, before it is clear it is good and necessary for PHP.
...
I agree with Stas, not just this paragraph but pretty all of the email.
Within the context of today's PHP language, practices, and the tried and
true libraries and frameworks we rely on, I don't know how, for certain
necessary semantics, to improve on Something or null return contracts.
I all honesty, I've looked for alternatives that satisfy a specific type
but I can't find anything better.
For example, I use the active record ORM from the Yii 2 framework. My
User model class therefore extends ActiveRecord. If I search for a User
record matching given criteria (e.g. an email address) the parent class
needs a generic way represent that no matching record exists and that
this is not an exception.
The convention in PHP is to return null in this situation. I have tried
to imagine how the search method might return an instance of the User
model class that represents "not a user record", i.e. the absence of any
user matching the search criteria. PHP's version of OOP seems not to
have a intrinsic feature for a function to return an object with type
Something but void of any Something object instance.
If PHP has nothing to model this, what convention can we invent as a
workaround to *encode* "empty" in an actual instance of ActiveRecord or
any subtype? A magic property can conflict with the app's model
attributes. But an ActiveRecord::isEmpty() method could work. This
satisfies the desire to return a specific subtype of ActiveRecord (e.g.
User) but it also introduces hazardous complexity: what do you do with
an instance in which the model's attributes, including primary key, are
valid but isEmpty() returns true, or vise versa.
Moreover, in what way is this better than returning PHP null? What have
we gained with this isEmpty() conventions?
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
