SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 60
  1. #26
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Of course if PHP has overloading of the [] accessor, all of this properties stuff would disappear.
    But it has. Or am I missing something here? Oo

  2. #27
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Aye, ArrayAccess interface

    offsetGet($name), offsetSet($name, $value), offsetExists($name), offsetUnset($name)

  3. #28
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ren
    offsetGet($name), offsetSet($name, $value), offsetExists($name), offsetUnset($name)
    Aye is right -- the cure is worse than the disease -- because you are right back to simple Container access with yet another set of accessor function names!
    Christopher

  4. #29
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    What do you mean by Model?
    I mean, a Model as in an object representing data or a process (basically yes, the M in MVC), and my question is, what makes that different than a DataSpace? Because it seems to be the same to me, and I would just call it a Model.

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I mean, a Model as in an object representing data or a process (basically yes, the M in MVC), and my question is, what makes that different than a DataSpace? Because it seems to be the same to me, and I would just call it a Model.
    The object you describe is a concrete class, whereas dataspace is an interface. So yes - the class is a dataspace, but it is also more than that. or not. maybe.
    It's a lot like the Iterator interface/pattern - it's rather useless to create an instance of ArrayIterator over an array and loop through it, contra just looping over the array. The power of iterator is that you expect some other code to implement the iterator-interface, so that you don't have to figure out how to loop over it.

    You might not like the name dataspace, but I think calling it model is a bad choice, since model is a layer - something more abstract than an interface. Then again, if you would have classes called Controller or View in your code, go ahead.

  6. #31
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    The object you describe is a concrete class, whereas dataspace is an interface. So yes - the class is a dataspace, but it is also more than that. or not. maybe.
    Ok, that makes perfect sense, although some the initial post implied dataspace as a class vs an interface.

    Quote Originally Posted by kyberfabrikken
    You might not like the name dataspace, but I think calling it model is a bad choice, since model is a layer - something more abstract than an interface. Then again, if you would have classes called Controller or View in your code, go ahead.
    I do have classes called Model and Controller, so I'm used to calling objects in the model layer Models; after all, they are models of (often) realworld objects or processes. However, I agree that it can be useful to define an interface that is implemented by models, because there are other things that are definitely not models that could implement the same interface. It's a testament to how difficult it is to name such a thing that Java went with Bean (which is more of a convention than an interface, I know, but it is pretty much the same thing.) One thing is certain to me, though, which is that whatever it is should ideally be a singular noun...

  7. #32
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    However, I agree that it can be useful to define an interface that is implemented by models, because there are other things that are definitely not models that could implement the same interface.
    I'm not sure that Models would implement a "DataSpace" like interface because they provide specific access to what they provide. Perhaps what Selkirk describes as Properties might be a Interface that Models might use. But I see the DataSpace interface as more of a Presentation layer thing where you need more generic interfaces for the stuff that gets used again and again.
    Christopher

  8. #33
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Aye is right -- the cure is worse than the disease -- because you are right back to simple Container access with yet another set of accessor function names!
    Might be worth it thou. For the compactness of $foo['property'] as opposed to $foo->get('property');

  9. #34
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I do have classes called Model and Controller, so I'm used to calling objects in the model layer Models; after all, they are models of (often) realworld objects or processes.
    I like to think that the model-layer is a little more than just data-centric objects. Collections of objects could belong there as well, or even something completely different, such as an SMTP-facade. Theese wouldn't implement DataSpace. But for 99% of the time, I agree - I just wouldn't call thoose objects Models for that reason.

  10. #35
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I'm not sure that Models would implement a "DataSpace" like interface because they provide specific access to what they provide. Perhaps what Selkirk describes as Properties might be a Interface that Models might use. But I see the DataSpace interface as more of a Presentation layer thing where you need more generic interfaces for the stuff that gets used again and again.
    Well, going by what Selkirk said:

    "Think of a dataspace as a pattern for objects to declare properties with accessor methods and a standard interface for accessing the properties of an object. Properties form the data access facet of a component model."

    And don't models need precisely that? A standard way of accessing its properties?

    I have a feeling we may not be meaning the same thing by DataSpace, which may a problem with the term.

    I like to think that the model-layer is a little more than just data-centric objects. Collections of objects could belong there as well, or even something completely different, such as an SMTP-facade. Theese wouldn't implement DataSpace. But for 99% of the time, I agree - I just wouldn't call thoose objects Models for that reason.
    Well, just as the Controller layer can have controllers and other types of objects, the Model layer can have Models as well as other types of objects. And Models can model processes as well; I think of Models as representation of things outside the system, which is usually a database, but could be anything really.

  11. #36
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But...

    Properties form the data access facet of a component model
    To me, you, or at least someone, are taking Selkirks component model terminology out of context; To me Selkirk wasn't specifically talking about the model, as in Model View Controller, but something that represents the system, or a part of the system.

    Such as a component part of the system, so from my point of view, the Model [MVC] has nothing to do with it at all, in that what a component model actually represents

    So... In that event, a Dataspace is an integrated part, and a part that plays an important role...

  12. #37
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I have a feeling we may not be meaning the same thing by DataSpace, which may a problem with the term.
    Yes. Above I noted that there are two different concepts. Selkirk is talking about a properties access scheme, that is different than the idea if a standard keyed container.
    Christopher

  13. #38
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "I have a feeling we may not be meaning the same thing by DataSpace, which may a problem with the term."

    I think so. A few people contributed definitions, maybe everyone else can?

    About the adding extra functionality (like you would to iterators) - what exactly would you add? I would very much appreciate a couple of examples...

  14. #39
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good thread.

    To restate the property pattern:

    An object should use the property pattern when it wants to expose data members as part of its public interface, but does not want to create external dependencies on the particular implementation used, such as storage or calculation.
    Quote Originally Posted by 33degrees
    It's a testament to how difficult it is to name such a thing that Java went with Bean
    Beans and properties are not the same concept.

    When I say the rectangle class has a height, a width, and an area property. It means that you can access any of those data members, but you are not allowed to or required to distinguish between which is stored or which is calculated. If the Rectangle class decides to cache area instead of calculating it, that is completely hidden behind the concept of a property. Properties are "abstract data members" and that abstraction hides the actual implementation.

    One area of confusion in PHP:

    PHP Code:
    class Rectangle {
        var 
    $area;

    In this example, area is a "concrete data member" of the Rectangle class. Which, confusingly, is generally called a property in PHP.

    Area may or may not also be a "abstract data member." That depends on the version of PHP you are using and your implementation of the property pattern.

    I won't elaborate on how much PHP sucks for implementing the properties pattern. That was pretty well established in the standard interface repository thread.

    So, beans are not properties, but beans ARE components. I won't even try to define what a component is. Instead, I'll turn to Anders Hejlsberg:
    The great thing about the word component is that you can just sling it about, and it sounds great, but we all think about it differently. In the simplest form, by component I just mean a class plus stuff. A component is a self-contained unit of software that isn't just code and data. It is a class that exposes itself through properties, methods, and events. It is a class that has additional attributes associated with it, in the form of metadata or naming patterns or whatever. The attributes provide dynamic additional information about how the component slots into a particular hosting environment, how it persists itself—all these additional things you want to say with metadata. The metadata enables IDEs to intelligently reason about what a component does and show you its documentation. A component wraps all of that up.
    Properties are just one facet of a component. A very important and useful facet.

    Quote Originally Posted by lastcraft
    This interface is for when the OO paradigm brushes up against things in the outside world that don't want to play ball. Requests, database rows, etc.
    Not exactly. Creating a (facade|adapter|wrapper|container) out of something thats not OO in order to make a component out of it is a good thing. However, there is more to the concept of a component and more to the concept of a property than just that.

    Rephrasing the questions that began this thread:

    What are the pros and cons of a property? What should a property do?

    What are the pros and cons of a component? What should a component do?

    What are the pros and cons of creating an OO interface for non-oo data? What should such an interface do?

  15. #40
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So, would caching be best implemented in a specialized datasources? I see advantages of this.

    Selkirk, thanks for making my questions better - I'll edit the topic, and add them, for any newer readers.

  16. #41
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Rephrasing the questions that began this thread:

    What are the pros and cons of a property? What should a property do?

    What are the pros and cons of a component? What should a component do?

    What are the pros and cons of creating an OO interface for non-oo data? What should such an interface do?
    The dialectic qualities of this forum are amazing. I had suggested that there was a difference between the Properties and Keyed interfaces, but quite honestly I hadn't a clue what exactly it was. But reading Selkirk's comments clarified a difference for me. Think about these two examples:
    PHP Code:
    class Rectangle {
        var 
    $width;
        var 
    $height;
        var 
    $area;
    }

    class 
    Request {
        function 
    get($key);
        function 
    set($keyvalue);

    Now let's look at how they might be used.
    PHP Code:
    $rectangle->width 10;
    $rectangle->height 10;
    $area $rectangle->area;

    $width $request->get('width');
    $height $request->get('height');
    $request->set('area'$width $height); 
    I get the sense that the Properties interface is for when there are known properties, whereas a Container (Keyed) is when there are potential properties. Also, with Properties you really don't know what is behind the names. In the Rectangle case, width and height are bounds checked values and area is calculated. Compare that to a Container where the assumption is that everything is stored the same way, even though the underlying storage medium is abstracted. But I still haven't anwered Selkirk's questions.
    Christopher

  17. #42
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Selkirk
    What are the pros and cons of creating an OO interface for non-oo data? What should such an interface do?
    In inflexible scripting languages it can unify data access, but I don't think that is as useful as is made out. You are unlikely to want to do the same operations on a DB row as you are on a request.

    I think the real reason is to change data access into messages. From there we can start to play (refactor) with such things as flipping control (tell, don't ask), moving the accessing functionality into the data centric class or using facades and mediators. The last is my current favourite, as I find data models and object models are rarely isomorphic.

    The interface is a first step to something better and may have no value in itself.

    I am sceptical something like PHP would ever need language support for properties. C++ is a strong typing nightmare and Ruby is at the opposite end of the spectrum, yet the topic never comes up.

    yours, Marcus

    p.s. So what is "binding"?
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  18. #43
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    ...Ruby is at the opposite end of the spectrum, yet the topic never comes up.
    I'm not sure what you mean by this, but Ruby most definitely has properties, as an object's variables are always protected; conveniently, you don't need to write getter and setters for each one, as this can be done with a single line using the attr_reader:, attr_writer:, and attr_accessor: shortcuts.

  19. #44
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    I'm not sure what you mean by this
    Not interfaces as in properties etc., but interfaces as in type safety.

  20. #45
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Not interfaces as in properties etc., but interfaces as in type safety.

    His entire sentence was "I am sceptical something like PHP would ever need language support for properties. C++ is a strong typing nightmare and Ruby is at the opposite end of the spectrum, yet the topic never comes up."

    Maybe he can clarify what he meant, because I don't think I understood the same thing you did.

    Quote Originally Posted by arborint
    I get the sense that the Properties interface is for when there are known properties, whereas a Container (Keyed) is when there are potential properties.
    Note that in the first case, there's no way to implement that as an interface, so it can only exist as a convention, which is what I was thinking of when I made the analogy to Java Beans.

  21. #46
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    So what is "binding"?
    Reply forthcoming.

    I am sceptical something like PHP would ever need language support for properties.
    language support isn't necessary. Java Bean properties have no special underlying language support. However, some people like to have language support for properties.


    More on properties:

    Consider a property as an "abstract data member" whose job is to shield clients of a class from the concrete implementation of that data member. (simple data field, cached, caclulated, accessor method, etc)

    The property pattern shields clients of a class from having to change when the implementation of the data member changes.

    You can also consider that a subclass is a client of its parent class. Thus, the subclass also should not have to change when the implementation of the data member changes in its parent. (Stable base classes are good.)

    Part of the inadequacy of __get and __set in PHP for implementing the property pattern is that it is outward facing only. Thus, the class itself and any subclasses do not get the abstract benefits of the property pattern.

  22. #47
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Part of the inadequacy of __get and __set in PHP for implementing the property pattern is that it is outward facing only. Thus, the class itself and any subclasses do not get the abstract benefits of the property pattern.
    This was partially fixed in 5.1 I believe....
    PHP Code:
    class A
    {
        function 
    __get($name)
        {
            if (
    $name == 'V')
                return 
    12;
            return 
    null;
        }
    }

    class 
    extends A
    {
        function 
    __get($name)
        {
            if (
    $name == 'VSquared')
                return 
    $this->$this->V;
        
            return 
    parent::__get($name);
        }

        function 
    getVSquared()
        {
            return 
    $this->$this->V;
        }
    }

    $b = new B();

    echo 
    $b->V"\n";
    echo 
    $b->getVSquared(), "\n";
    echo 
    $b->VSquared"\n"
    Does output 12, then 244 twice as expected.

  23. #48
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I am sceptical something like PHP would ever need language support for properties. C++ is a strong typing nightmare and Ruby is at the opposite end of the spectrum, yet the topic never comes up.
    Spidermonkey let's you do this :
    Code:
    function Point( x, y ) {
      this.x = x;
      this.y = y;
    }
       
    Point.prototype.__defineGetter__(
      "dimensions",
      function() { return [this.x, this.y]; }
    );
       
    Point.prototype.__defineSetter__(
      "dimensions",
      function( dimensions ) { this.x = dimensions[0]; this.y = dimensions[1]; }
    );
    It have come quite handy more than once. I'm just sorry it's not standard ecmascript.

  24. #49
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by 33degrees
    His entire sentence was "I am sceptical something like PHP would ever need language support for properties. C++ is a strong typing nightmare and Ruby is at the opposite end of the spectrum, yet the topic never comes up."

    Maybe he can clarify what he meant, because I don't think I understood the same thing you did.
    Because unlike Java, Ruby and C++ have complete operator overloading. Right now PHP has a leaky (like a sieve) abstraction with __get() and the SPL. Even Perl does it better .

    Why write a whole other syntax on top of the OO grammer? Complete the overload and array abstractions instead. That way OO programmers can even write libraries with non-OO interfaces. But, let's not call them "ties" .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  25. #50
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    His entire sentence was "I am sceptical something like PHP would ever need language support for properties. C++ is a strong typing nightmare and Ruby is at the opposite end of the spectrum, yet the topic never comes up."
    Hm, indeed. My fault for not reading through properly.
    Quote Originally Posted by kyberfabrikken
    It have come quite handy more than once. I'm just sorry it's not standard ecmascript.
    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? Or do you mean Spidermonkey does exactly that?
    Quote Originally Posted by lastcraft
    Why right a whole other syntax on top of the OO grammer?
    I still don't seem to get where you're headed at all.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •