How useful is a Dataspace?

[arborint]

This was partially fixed in 5.1 I believe....

Does output 12, then 244 twice as expected.

Yes, but it is still an error handler for undefined properties. If they added __get_all() and __set_all() that trapped all accesses then we would be getting closer.

[Ren]

@Ezku, Spidermonkey provides the non-standard magic __defineSetter__ and __defineGetter__ methods for objects. Its just Spidermonkey specific.

There are proposals for introducing getter and setting syntax like

function get X():int { return this.x; }

into the ecmascript syntax, see http://www.mozilla.org/js/language/e...variables.html but no idea when/if it ever get there.

[lastcraft]

Hi...

I still don't seem to get where you're headed at all.

Neither do I .

I guess I am saying that if the PHP engine was completed in an orthogonal way, we could just make our objects look like arrays when needed. I'd hate to see language extensions like the Java Properties system for example.

yours, Marcus

[33degrees]

Javascript is really cool in its extensibility. I'm not that experienced with it, but can't you rather easily extend the base object so that those capabilities are introduced to every object?

Yes. Javascript is prototype based, and there are no classes; when you create an object of a given type you're actually cloning the prototype. And since you can add methods to objects at run time, if you add a method to the prototype, all classes based on that prototype now have that method.

Javascript is a really cool language, the problem is most people get exposed to it via dom scripting, which can be laborious, so they dismiss the language itself. But I find it a much more powerful and expressive than php.

[kyberfabrikken]

Or do you mean Spidermonkey does exactly that?

__defineGetter__ and __defineSetter__ are magic methods just like php's __get and __set. So yes, Spidermonkey let's you do that on all objects. It's very useful for hacking api mismatches between IE and FF.

Javascript is a really cool language, the problem is most people get exposed to it via dom scripting, which can be laborious, so they dismiss the language itself. But I find it a much more powerful and expressive than php.

I totally agree. JS is so underestimated. Perhaps one day ...

Oh well. Think we got a bit off topic there ...

[Dr Livingston]

so either both should operate on array or both should operate on IDataspace.

In the event you have an array, I would use the following; I have not found any situation where I've needed anything more, for what it's worth

class Parameters extends Dataspace {
        public function __construct( $parameters ) {
            foreach( $parameters as $parameter => $value ) {
                $this -> set( $parameter, $value );
            }
        }
    } 

That way, you can still have the Dataspace implementation for an array, and at the same time you can export it as an array; I don't see the point therefore, of having class methods that basically do the same thing, bar one pair of methods require an Interface, in your case (going by an earlier post)

[dbevfat]

more than 1 month old, eh?

Yes, I agree, a Dataspace wrapper around an array is a better solution.

The reason I posted my suggestion is purely philosophical. It's - in my perspective - lack of consistency in your example (no offense meant, just being strictly and anoyingly accurate). Your import and export methods operate on different data structures. Their names, howerer, imply that these two methods are opposites of one another, so I think one would automatically expect them to operate on the same data structure. And it doesn't really matter if it is an array or an IDataspace, as long as both methods use the same structure.

But, there is no sense in an IDataspace returning another IDataspace with the same data. It's basically returning itself, which is useless. So, the export() method should return an array. But then it's either:
- import methods takes an array, or
- import method gets renamed.

Maybe it's just the name of the import() method that doesn't quite fit in the picture?

I repeat, this is very philosophical and quite irrelevant to any "good practice". Maybe it's even my own problem, for seeing import and export as reverse functions. But, I've at least explained (quite accurately) what bothers me.

Best regards

[Dr Livingston]

Umm...

I just think your picking at straws... With the classes I posted, you can import both to an IDataspace, and an array, whereas in any event, you export to an array;

But let's just agree to disagree with this issue, as it's pretty obvious that we both have different uses, or points of view, on how to use something like this anyways

Before this thread cashes it's pension, is there anyone else who wants to add their pennies worth to it?

[dbevfat]

I just think your picking at straws... With the classes I posted, you can import both to an IDataspace, and an array, whereas in any event, you export to an array;

But let's just agree to disagree with this issue, as it's pretty obvious that we both have different uses, or points of view, on how to use something like this anyways

Agreed, I am picking at straws, but just because I think language matters - functions with names that describe opposite behaviour should perform reverse operations (which would result in operating on the same data structure).

Just as implode(array) returns string, explode(string) returns array. Reverse functions with reverse operations. Quite similar to import and export.

I apologize for pushing this so much, I don't really want to convince anybody, I'm just trying to explain what I mean. I agree with you on disagreeing with this - as long as you understand what I mean

regards

[Dr Livingston]

I agree with you on disagreeing with this - as long as you understand what I mean

Yes, I do know what you mean, but from the opposite side