> > apologies if I've missed it, but have you actually said what that use case > is?
Sorry if it wasn't clear in my original post. The use case is the following: - a data mapper retrieves an object from the database - for optimization purposes, we can ask the data mapper to return a partial object, with only a handful of properties initialized - when saving the (potentially partial) entity to the database, the data mapper needs to read initialized properties only So this would require to be able to quickly (faster than reflection) detect if a property is initialized before attempting to read it. To summarize what's been said so far (provided that my understanding is correct, as I haven't received additional feedback from Nikita yet): - an additional language construct similar to isset(), but returning true for null values, would not be particularly welcome - an additional function such as property_is_initialized() could do the job Note that I don't want to be pushy for an additional opcode for property_is_initialized(), this can be discussed later if benchmarks justify it. For now, just adding this additional function should be enough to bring at least a 2x performance improvement over reflection when reading all *initialized *properties from an object (benchmarked using a no-op function that always returns true). Ben On Wed, 6 Feb 2019 at 23:21, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 06/02/2019 22:10, Benjamin Morel wrote: > > But we digress, can we focus on whether to add another isset()-like > > construct, or a property_is_initialized() function, ideally with a > > companion opcode to speed it up? > > I apologise for the digression. However, there is some relevance, > because asking for not just a new function, but a new opcode, suggests > you have a use case that is both common and performance critical; > apologies if I've missed it, but have you actually said what that use > case is? > > > > Pardon my ignorance, but what is exactly increasing the language > complexity? Do you mean the addition of a language construct to the parser? > > Notice that Nikita said "conceptual language complexity", not > "implementation complexity" - regardless of how simple this is in > implementation, it's one more thing to document, maintain, and answer > questions about. > > > Regards, > > -- > Rowan Collins > [IMSoP] > >
