loading...

re: What's the deal with downing PHP development? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: PHP's a language people love to hate. It's messy, it's clunky, the standard library uses inconsistent nomenclature, it lends itself to a multitude ...
 

I get everything you say! I've made those same observations. I do like your point in which you said people who haven't even coded in it already dismiss it.

NodeJs is the new nice and shiny everyone is falling in love with. But ES5 currently doesn't even support classical OOP. So if the argument is that a language is fundamentally bad because it has faults, then why aren't languages like Javascript and NodeJS being looked at in the same light? Because they certainly do have their issues. Proven by the point that we needed to create Typescript.

 

Many people don't take JavaScript seriously either thanks to its checkered history and common usage on the frontend. PHP is just lower on the totem pole.

For what it's worth, I consider prototypal inheritance and a lack of type safety reasons for using JavaScript. If I wanted classical OOP and static types, I'd use a language built around classical OOP and static types.

Interesting. What scenario would you say a developer might want a prototype model over plain-old OOP?

Many! Composability is a really powerful technique with a host of applications, and it's much, much easier to accomplish with a prototypal model than it is with classic object orientation.

For a concrete example, I maintain a data access library which introspects a database to build an API over it. A database contains tables, views, functions, and schemas. Tables can be read and written; views can be read; functions can be executed; schemas act as namespaces and contain objects of the other three types. The first three object types have certain attributes in common: a name, a schema they belong to, et cetera.

A classic OO approach would be to create an Entity class which centralizes the common attributes, and have each of Table, View, and Function inherit Entity. A method may act on any "real" database object (omitting schemas, which just contain things) as long as it takes an Entity and either only references Entity properties and methods or performs the appropriate checks and casts.

Then you get into the "building an API" stage. The goal is to return a Database tree that lets you issue a statement like db.things.stuff.find(), where things is a schema and stuff a table, determining the query target by navigating the tree. This isn't so hard: simply ensure that you create namespaces and attach Entities at the appropriate path.

However: the default schema is unnamespaced, so what happens when it also contains a table named things? What do you do now? Classic OOP has no easy answer. Do you create classes for TableWhichIsAlsoASchema and TableWhichIsAlsoAFunction and all the other possible collisions? Do you cross-contaminate your three base classes and gate alternative logic behind introspection checks? Good luck!

With prototypal inheritance, resolving these collisions isn't just possible, it's easy: just keep applying prototypes as they come in! If you already have a Table at a path which turns out to resolve to a schema as well, you can just hang the new stuff on the existing object. The only collisions that can't be resolved are due to (small-f) functions being overridden or becoming ambiguous, not due to simple pathing.

 

But ES5 currently doesn't even support classical OOP.

I hate to break it to you, but many of us consider this a feature, not a bug.

If you value Composition over Inheritance then Javascript is for you. In any case I don't think it is fair to consider this a "fault", and many people (myself included) think that introducing class in ES5 was a big mistake.

This isn't to open a flame war about OOP vs. Functional programming. Just that if your language is good at functional programming, you should double down on that, rather than adding functionality for OOP-driven developers who don't understand why Javascript is a powerful functional language, and how to leverage that.

So you get people using classical inheritance patterns in a language that's meant for prototypal inheritance.

 

The thing with Javascript is, you have no real choice about using it on the front end. I think a lot of the server-side momentum is driven by this fact. The thinking being that a dev can leverage the knowledge that already have for the server side too.

I consider Javascript far worse than PHP (and I don't care for PHP that much after writing a lot of things in it). But that does not alter my lack of choice about whether to use Javascript. If I were coming at this thing fresh, I would be tempted to try to use the same non-optional language across the board too.

Code of Conduct Report abuse