Object-oriented argument passing



  • The application I'm currently supporting has a funny way of using OOP. Somewhere along the development, the original programmers discovered classes and their beauty. Like, for example, how you can instance an object to keep values on it. And then discard the object.

    [code]$empdata = new employee(strtoupper($GetEmployeeData[emp_name]), strtoupper($GetEmployeeData[emp_email]));[/code]
    [code]$Result = RemoveEmployee($empdata->name, $empdata->Email);[/code]
    [code]return $Result;[/code]


  • Doesn't PHP follows the same naming principles many other languages use?

    Please, please, add the RemoveEmployee implementation. I would love to see how they discard an object in a garbage collected environment. I bet on $data = new employee(name,email); $data = null;



  • The object will be discarded when it exits scope with the return statement.



  • @pjt33 said:

    The object will be discarded when it exits scope with the return statement.
     

    That depends on the language. I'm not familiar with the PHP gc system, but in Java it definitly isn't



  • Indeed, which I why I gave the PHP behaviour. It shouldn't really be necessary to quote the last post in the thread for it to be apparent that I'm replying to it. Especially given that there's an "In reply to" link on the post.



  • @pjt33 said:

    Indeed, which I why I gave the PHP behaviour. It shouldn't really be necessary to quote the last post in the thread for it to be apparent that I'm replying to it. Especially given that there's an "In reply to" link on the post.
    Who are you talking to?


  • 🚽 Regular

    IIRC, people put little concern on memory management with PHP because unlike other runtimes, each access to a PHP script (via a page load, for example) merely forks a new apache process which exits at the end of its short life cycle when the webpage is delivered to the client, effectively freeing any memory that allocated by the script. Unless you're doing stuff like long-term background operations or something, most people don't spend too much time worrying about memory management. That being said, I believe the Zend Engine, anyway, uses a garbage collector, but don't quote me on that.



  • @RHuckster said:

    IIRC, people put little concern on memory management with PHP because unlike other runtimes, each access to a PHP script (via a page load, for example) merely forks a new apache process which exits at the end of its short life cycle when the webpage is delivered to the client, effectively freeing any memory that allocated by the script. Unless you're doing stuff like long-term background operations or something, most people don't spend too much time worrying about memory management. That being said, I believe the Zend Engine, anyway, uses a garbage collector, but don't quote me on that.
    Yes, it does, but it's only there to clean up circular references, which the ordinary reference-counting mechanism misses. But you'd have to be dealing with tens of thousands of objects simultaneously before it bothers to kick in.

    It would be an unusual (or unusually badly written - which is probably the usual situation)  web page script that won't run to completion first (and then as you say, all the memory allocated to the PHP runtime would be freed); for the garbage collector to be relevant you'd be more likely doing something other than scripting web pages.

     

    But this code makes me weep. It's as if the original developers not only discovered the beauties of OOP "somewhere along the way", but they simply half-grafted them on to what they had at that moment and kept going, and avoided going back to change what had already been written.

    Are you sure there weren't [i]two[/i] sets of developers, working at different times?



  • It seems that they're treating PHP classes as C-style structs, which can only have fields, not methods. I'm betting the original coders were C programmers who got into the "web thing". (I'm making an unwarranted assumption this code is from a webapp. If it's not, we need to nuke it from orbit.)



  • @RHuckster said:

    IIRC, people put little concern on memory management with PHP because unlike other runtimes, each access to a PHP script (via a page load, for example) merely forks a new apache process which exits at the end of its short life cycle when the webpage is delivered to the client, effectively freeing any memory that allocated by the script.

    That's interesting... though, wouldn't this approach lead to inefficiency when dealing with, say, a website with 50,000 concurrent users? Fifty thousand threads doing the same thing with no shared overhead... eek!


  • Discourse touched me in a no-no place

    @ekolis said:

    @RHuckster said:
    IIRC, people put little concern on memory management with PHP because unlike other runtimes, each access to a PHP script (via a page load, for example) merely forks a new apache process which exits at the end of its short life cycle when the webpage is delivered to the client, effectively freeing any memory that allocated by the script.

    That's interesting... though, wouldn't this approach lead to inefficiency when dealing with, say, a website with 50,000 concurrent users? Fifty thousand threads doing the same thing with no shared overhead... eek!

    Web servers tend to have a pool of threads (with upper and lower limits on the number of them) - it is those that fork a single new thread to handle things like php. See the relevant pages for apache or (possibly less relevant) lighttpd



  • Not forgetting caching technology  available for PHP, like memcached , eAccelerator and the like. Similarly there's caching MySQL side if the site is a standard LAMPy package, like a blog or forum, and has many repeated hits to the backend DB.

    (I once optimised some site code for a 40,000-user site simply by moving the nested loop and summary functions out of PHP and into MySQL with aggregate functions and GROUP BY. A 2-hour script dropped to 5 mins. Added indexes, and it dropped to 20 seconds. Yes, it's an old "PHP devs weren't DB devs" pattern all over again...)
     



  • @Cassidy said:

    (I once optimised some site code for a 40,000-user site simply by moving the nested loop and summary functions out of PHP and into MySQL with aggregate functions and GROUP BY. A 2-hour script dropped to 5 mins. Added indexes, and it dropped to 20 seconds. Yes, it's an old "PHP devs weren't DB devs" pattern all over again...)

    I've talked about that in the past, about how a high proportion of programmers don't understand, and in fact actually fear SQL, even when they could save tons of time and effort by adopting it. Sounds like the product you improved was written by those programmers.



  • Amen. No idea why some apps devs seem so frightened of DB stuff, or reluctant to try it.

    Then again, I'm of the view DB devs should be creating stored procedures and/or views, writing queries, joins etc, leaving apps devs to call these SPs and parse results, thus separating out the two disciplines. Horses for courses and all that.

    I've no objection for apps devs to learn DB stuff, but... jack of all trades and master of none, etc.

    (admittedly the app in question in this case used MySQL, which didn't support SPs at the time.)



  • @Cassidy said:

    Amen. No idea why some apps devs seem so frightened of DB stuff, or reluctant to try it.

    My pet theory is that it has a lot to do with all DBAs being assholes.

    @Cassidy said:

    (admittedly the app in question in this case used MySQL, which didn't support SPs at the time.)

    Jesus. Who wants to apply for a grant to figure out why the holy fuck MySQL is still around and popular after being a gigantic ball of shit for a solid decade?



  • @blakeyrat said:

    My pet theory is that it has a lot to do with asshole DBAs

    FTFY. Not going to defend DBAs, but most DBAs that are arseholes aren't effective DBAs. They're arseholes with a superiority complex, and are dropped into a DBA position that grants them power to abuse and generally act like a nest-feathering defensive dickwad. Decent DBAs are data managers that guarantee database functionality is always available when needed, and spend more time involved in discussions concerning how the data stores can best serve the needs of the business. 

    Unfortuntely, this last lot are few and far between. I've had the pleasure of training up the latter (and the pleasure of taking the former down a peg or two) but you don't need to be a DBA to be an arsehole.

    @blakeyrat said:

    Jesus. Who wants to apply for a grant to figure out why the holy fuck MySQL is still around and popular after being a gigantic ball of shit for a solid decade?

    Its maturity levels began with - and grow with - those of the novice PHP programmer hacking out a codebase for their MMORPG's webshite.

    My bill is in the post. I thank you.



  • @Cassidy said:

    @blakeyrat said:

    My pet theory is that it has a lot to do with asshole DBAs

    FTFY.

    No. You didn't. You edited my text to insert your opinion. What do I have to do to get this asshole meme to die?

    @Cassidy said:

    EVERY MORNING I FUCK DONKEYS IN THE ASS FOR 3 HOURS

    FTFY.

    How do you like it? Huh? Huh? Yeah. Taste your own medicine. Taste the rainbow of fruit pain.



  • @blakeyrat said:

    @Cassidy said:

    @blakeyrat said:

    My pet theory is that it has a lot to do with asshole DBAs

    FTFY.

    No. You didn't. You edited my text to insert your opinion. I need to create a better meme so that this one will die.
    FTFY


  • @Cassidy said:

    Then again, I'm of the view DB devs should be creating stored procedures and/or views, writing queries, joins etc, leaving apps devs to call these SPs and parse results, thus separating out the two disciplines. Horses for courses and all that.

    That only works in a waterfall type project where you get to plan and divide all the work out early - and get it right in the planning stages. It also leads to dead code in the database because the DB developer doesn't know what is called from where. In my opinion, if a person or group is to be dedicated to data layer work, they should be responsible for both the database schema and the data access layer of the application. A lot of really high-performance solutions require that both the database and the calling code be set up properly. For example, MSSQL 2008 and later support a table-valued parameter that dove-tails nicely with .Net DataSets. The appropriate SQL 2005 solution is to use an XML parameter, which lends itself to XML data in the application.



  • @Jaime said:

    @Cassidy said:

    Then again, I'm of the view DB devs should be creating stored procedures and/or views, writing queries, joins etc, leaving apps devs to call these SPs and parse results, thus separating out the two disciplines. Horses for courses and all that.

    That only works in a waterfall type project where you get to plan and divide all the work out early - and get it right in the planning stages. It also leads to dead code in the database because the DB developer doesn't know what is called form where. In my opinion, if a person or group is to be dedicated to data layer work, they should be responsible for both the database schema and the data access layer of the application. A lot of really high-performance solutions require that both the database and the calling code be set up properly. For example, MSSQL 2008 and later support a table-valued parameter that dove-tails nicely with .Net DataSets. The appropriate SQL 2005 solution is to use an XML parameter, which lends itself to XML data in the application.
    But why can't the DBA say "this is the type of this parameter" and the application developer can use the appropriate type?


  • @Sutherlands said:

    @Jaime said:

    @Cassidy said:

    Then again, I'm of the view DB devs should be creating stored procedures and/or views, writing queries, joins etc, leaving apps devs to call these SPs and parse results, thus separating out the two disciplines. Horses for courses and all that.

    That only works in a waterfall type project where you get to plan and divide all the work out early - and get it right in the planning stages. It also leads to dead code in the database because the DB developer doesn't know what is called form where. In my opinion, if a person or group is to be dedicated to data layer work, they should be responsible for both the database schema and the data access layer of the application. A lot of really high-performance solutions require that both the database and the calling code be set up properly. For example, MSSQL 2008 and later support a table-valued parameter that dove-tails nicely with .Net DataSets. The appropriate SQL 2005 solution is to use an XML parameter, which lends itself to XML data in the application.
    But why can't the DBA say "this is the type of this parameter" and the application developer can use the appropriate type?

    Because then you get stupid crap like a DataSet that was converted to XML for the SQL 2005 version of the application, that then gets re-packaged as a second DataSet after the procs are update to take advantage of 2008.

    It's also possible to run into situation where the technologies are hard to match -- for example, it's difficult to call a procedure with a table-valued parameter if the data access layer is based on TableAdapters.

    Besides, the DBA saying "this is the type of this parameter" and being dead-wrong for the application is a classic example of an asshole DBA move.



  • @blakeyrat said:

    No. You didn't. You edited my text to insert your opinion. What do I have to do to get this asshole meme to die?

    @Cassidy said:

    EVERY MORNING I FUCK DONKEYS IN THE ASS FOR 3 HOURS

    FTFY.

    Incorrect. At weekends I often get up late, so occasionally the donkeys get a break until the afternoon.

    SO IT'S NOT EVERY MORNING! That told you.

    @Sutherlands said:

    But why can't the DBA say "this is the type of
    this parameter" and the application developer can use the appropriate
    type?

    They can, or something like it: it's called defining and agreeing interfaces between data source and application (bit like agreeing a contract between the two disciplines), so the two groups thrash out what's being sent (parameters) and what's being received (returned). Not always done by the DBA - more commonly by the PL/SQL Devs.

    @Jaime said:

    It also leads to dead code in the database because
    the DB developer doesn't know what is called form where.

    It only leads to dead code in situations where DB devs aren't appraised when app devs deprecate the only class/interface that calls a particular SP.  That's really a flaw in organisational communication and the change management process. In most cases, the DB Dev doesn't need to care where in the codebase the calls are coming from, just that they're required.

    @Jaime said:

    In my opinion, if a person or group is to be
    dedicated to data layer work, they should be responsible for both the
    database schema and the data access layer of the application.
     

    I think that was my original point...  wasn't it? Or did I miss something?



  • @Cassidy said:

    @Jaime said:
    In my opinion, if a person or group is to be
    dedicated to data layer work, they should be responsible for both the
    database schema and the data access layer of the application.
     

    I think that was my original point...  wasn't it? Or did I miss something?
    You missed something... SPs and views are not the data access layer, they are part of the schema.



  • Erm.. actually, you're right on that front - they ARE part of the schema.

    However, I looked at them as being a data interconnectivity point (a layer between the tables and the code) so imagined the schema being constructed outside of the code devs, then views/SPs being used to connect app code to the tables.

    I probably didn't explain that too well. Or to summarise: I MISSED SOMETHING!

    Apologies for confusion. Hope that helps!



  • @Cassidy said:

    @Jaime said:

    It also leads to dead code in the database because
    the DB developer doesn't know what is called form where.

    It only leads to dead code in situations where DB devs aren't appraised when app devs deprecate the only class/interface that calls a particular SP.  That's really a flaw in organisational communication and the change management process. In most cases, the DB Dev doesn't need to care where in the codebase the calls are coming from, just that they're required.

    The organisational communication problems are almost guaranteed by the following attitudes...
    @Cassidy said:
    Then again, I'm of the view DB devs should be creating stored procedures and/or views, writing queries, joins etc, leaving apps devs to call these SPs and parse results, thus separating out the two disciplines. Horses for courses and all that.

    @Sutherlands said:
    But why can't the DBA say "this is the type of this parameter" and the application developer can use the appropriate type?

    @blakeyrat said:
    My pet theory is that it has a lot to do with all DBAs being assholes.



  • @Jaime said:

    The organisational communication problems are almost guaranteed by the following attitudes...

    I don't see how.

    I won't disagree that attitudes, opinions, feelings, behaviour and culture contribute to communication problems - but IME communication problems generally arise as a result of slack policy and poor process governance.

    (I did say "horses for courses" in my observations, implying appropriateness where necessary rather than my suggested model being blindly adopted without proper benefits analysis and approval channels.)


Log in to reply