Loading ...
Sorry, an error occurred while loading the content.

Re: [php-objects] Forms question

Expand Messages
  • Manuel Lemos
    Hello, ... I think the argument is that many people s code is slow because of this unintended object copying. A lot of people don t understand the difference
    Message 1 of 46 , May 7, 2002

      Lux wrote:
      >>>>object duplication with all memory waste and CPU penalties. With PHP 5
      >>>>that will only be a reference duplication like it is with Java. That may
      >>>> break some software that incidently was relying on the object copying.
      > I'm afraid I don't quite see the point of the change, especially since
      > it will break b/c with 4.x. As PHP currently stands, the new
      > functionality can be achieved like this:
      > $DBobj = new DB();
      > $Variables[DBobj] =& $DBobj;
      > And since the & is added, we can see that this is a reference. Taking
      > this out makes it less obvious that it is a reference (is $b = 5; $a =
      > $b; a reference also?). Sure there is a performance penalty in
      > duplicating objects, but as it stands the onus is on the programmer to
      > be aware of that, and make references where appropriate. But at least
      > the syntax is different, so references can be easily spotted.
      > Am I missing something?

      I think the argument is that many people's code is slow because of this
      unintended object copying. A lot of people don't understand the
      difference between a copy and a reference so they have no idea of the
      performance penalty.

      Changing the default behaviour and making PHP more like Java it will
      articificially speed up some people's code.

      >>Btw. I havenĀ“t seen documentation on PHP5 yet that explains how or if it
      >>is still possible to copy an object if you need to.
      > I sure hope it is, since I do rely on this ability right now.

      There is always the option of not using PHP 5 at all. I am afraid it
      will break compatibility in more ways than this. I have yet to see any
      compelling reason to use PHP 5, other than it looks more like Java. If I
      wanted something more like Java, I would use Java. Now, I am not going
      to keep 2 versions of my PHP code to work on incompatible PHP versions.

      Manuel Lemos
    • Wayne Venables
      ... It s wrapped in a template (regular PHP page). The table itself uses a template (again, another PHP page) to render the table itself (basically, the
      Message 46 of 46 , May 9, 2002
        At 05:57 PM 09/05/2002, you wrote:
        > > What I use is a class thatdisplays a tabular list of items. It's an
        > > abstract base class -- so on it's own, it does nothing.
        >Excellent suggestion, I'll investigate further. Do you wrap this with a
        >template page, or is the page itself an object?

        It's wrapped in a template (regular PHP page). The table itself uses a
        template (again, another PHP page) to render the table itself (basically,
        the skin).

        >Also, I've seen several posts mention the use of a superclass to handle db
        >connections. Is this a common practice? For my app I created a smallish db
        >class and, instead of inheriting, I make it global in my other class
        >methods. It seems to work fine for me, but I'm not doing super-sophisticated
        >db stuff. Anyone care to share pros or cons for either approach?

        I have a database connection class which I stuff in a global variable to
        make it available to all the class (and regular code) in the script. The
        connection class contains methods for connecting to the database and
        executing queries. However, objects which use the database generally
        inherit from a more generic base class which handles database tasks common
        to all objects (namely inserting new objects, updating objects, deleting

        >I *do* have a global application class for tracking application state (which
        >user is logged in, what task he is manipulating), but I'm beginning to this
        >think this is a mistake. The main reason is because PHP sessions timeout
        >and I lose the (registered) global object if there is no activity for a
        >while. So I'm thinking I'll just go back to URLs and hidden fields for these
        >kinds of things. Any ideas?

        A hybrid design is the best course of action. Sessions timeout because you
        never know if someone has closed their browser. It's the period of
        inactivity, which is probably good for login information. URLs and hidden
        fields are "insecure" so you probably don't want to use that to store which
        user is logged in. But you probably do want to use URLs and hidden fields
        for tracking which task he is manipulating. If the user opens two browser
        windows on your app, storing it globally will make that application behave
        more erratically. (For example, I wouldn't be able to have two different
        tasks open in different windows, because you store that globally).


        WebMotif Net Services, Inc.
        Direct: 604.299.1908
      Your message has been successfully submitted and would be delivered to recipients shortly.