Mappings got generation counters yesterday. Although the overhead is fairly small (poking a flag on every change, and added storage in each mapping_data for a 32 bit counter), so is the utility; it at least deserves some discussion whether it should be there or not.
Aside from that, I got a couple of remarks on the implementation:
o The new builtin function m_generation isn't critical enough to deserve a place on the global level imho.
o If this is the way to go, it's not far fetched that generation counters will be added to the other data types too. Thus the names "m_generation" and "_m_generation" (for the lfun) aren't generic enough. Simply "generation" and "_generation" seems better.
To detect whether a mapping has changed:
int n = m_generation (the_mapping);
...
if (m_generation (the_mapping) != n) { n = m_generation (the_mapping); do_stuff (the_mapping); } else werror ("we're still fine\n");
This is in most cases possible to implement with a wrapper object instead.
On Wed, 25 Jun 2008 13:05:02 -0000, Martin Stjernholm, Roxen IS @ Pike developers forum 10353@lyskom.lysator.liu.se wrote:
This is in most cases possible to implement with a wrapper object instead.
Is there a concrete reason (problem case) to have it in the language? You are saying "most" - what are the cases where using a wrapper object does not work?
Bernd
On Wed, 25 Jun 2008 13:05:02 -0000, Martin Stjernholm, Roxen IS @ Pike developers forum 10353@lyskom.lysator.liu.se wrote:
This is in most cases possible to implement with a wrapper object instead.
Is there a concrete reason (problem case) to have it in the language? You are saying "most" - what are the cases where using a wrapper object does not work?
Eg in the case at hand; a mapping that is modified directly by C-code, or if there's a preexisting mapping that needs to be monitored.
Bernd
Any example where this is used/useful?
(I'm not doubting it's usefulness, I'm just curious.)
Is the problem we are solving a faster overloading than if this generation stuff was handled internally in the object?
The generation counter wrapper would have to be around the mapping being shadowed. So ShadowedMapping wouldn't be able to take an ordinary mapping for shadowing if the generation stuff isn't built into it.
Otoh, the generation counter is only necessary for a cache inside ShadowedMapping. I think it'd work pretty well without that cache too, so imo it's not worth the overhead in all mappings. Is there something else to motivate having built-in generation counters?
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Otoh, the generation counter is only necessary for a cache inside ShadowedMapping. I think it'd work pretty well without that cache too, so imo it's not worth the overhead in all mappings. Is there something else to motivate having built-in generation counters?
My gut feeling is that this is going overboard. I see limited use. You could, use it is a debugging aid, but even then the value is questionable.
I'd prefer not to extend the language with this overhead.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Otoh, the generation counter is only necessary for a cache inside ShadowedMapping. I think it'd work pretty well without that cache too, so imo it's not worth the overhead in all mappings. Is there something else to motivate having built-in generation counters?
The cache is needed for keeping indices() and values() stable.
My gut feeling is that this is going overboard. I see limited use. You could, use it is a debugging aid, but even then the value is questionable.
I'd prefer not to extend the language with this overhead.
Since the consensus seems to be against having generation counters, I've just removed the implementation.
The main use case (monitoring an external mapping) can be done by utilizing deferred copy and equal() albeit at a minor performance loss:
* The copy will be realized at first edit.
* equal() is an expensive operation if the compared mappings are substantially similar but not the same (ie one is a deep copy of the other), but this is probably unlikely in practise.
-- Sincerely, Stephen R. van den Berg.
On Wed, Jun 25, 2008 at 12:55:02PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
o The new builtin function m_generation isn't critical enough to deserve a place on the global level imho.
i think we should reduce the global level as much as possible, people get confused as to where to find things. anything that also fits in another place should go there. at least for the less often used stuff.
how about Mapping.generation()?
o If this is the way to go, it's not far fetched that generation counters will be added to the other data types too. Thus the names "m_generation" and "_m_generation" (for the lfun) aren't generic enough. Simply "generation" and "_generation" seems better.
i agree with that.
greetings, martin.
I think grubba have talked about it before, but I didn't expect it to show up at this point. Is there something we need this for grubba, or can we postpone it until after the release?
pike-devel@lists.lysator.liu.se
-
Bernd Schoeller -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg