PHP OOP

[Thor]

That's luckily something that was drilled into me. My code reads like a book so much comments and comment instructions it would most like irritate everyone I also include a roadmap.txt outside of the public folder for reference that outlines the file structure, the includes and a list of functions etc basically anything useful to have an index to work through 3 years from today

 

[[)roi(]]

I've found that it's mostly about trade-offs.

The trade off to this is how readable is the code to 90% of people writing and maintaining php and is having the readability knock worth the 0.00005 second saving?

if this is in reference to FP, then remember they're just another function like substr, granted they've been written to be far more flexible and extensible than a average function; but doesn't immediately imply unreadability. Remember the first time any language was created, it's syntax would have been foreign, similarly when new features were introduced like covariance and contravariance, just because you didn't know it, doesn't mean the rest of the team shouldn't use it, or have to litter their code with training wheels (the stuff you should find in function reference).

You should have also seen that the inners workings of the flatmap example I shared is not something foreign: it has foreach loops, null checks, and a call back function -- all common elements in code.

Most of all, Comment Your Code (something I don't do often enough) so the person coming after you (usually you in 3 years) knows what you were thinking, planning and doing. In that 3 years your method of thinking is probably going to have changed and you're going to be wondering why you did something in a certain way - leave clues behind so you can remeber why.

Agreed, but the level of commenting shouldn't overstep a language reference, but rather explain difficult or compex techniques; but again as with anything, within reason.

Personally I prefer code comments to follow a standard; a good approach is always to write (htmldoc) documentation comments as these can then be turned into html documentation (htmldocs). Almost every language has a facility for this, with PHP it's e.g. https://www.phpdoc.org.

Excessive comments in code is only a source of frustration when you fail to keep it updated, and yes that implies every programmer working with the codebase. There is nothing more frustrating than finding stale comments that don't reflect the changes.

That said the amount or proliferation of internal comments (not htmldocs) is always going to be more when you're starting out or trying to deal with the unfamiliar.

 

[BandwidthAddict]

OOP and FP are merely tools. A child plays with tools and may even have a favourite but a master has such mastery over all available tools that they are transparent while the solution is being crafted.

 

[[)roi(]]

OOP and FP are merely tools. A child plays with tools and may even have a favourite but a master has such mastery over all available tools that they are transparent while the solution is being crafted.

As for OOP & FP being merely tools, I get the general idea, but it's really not a great analogy especially the part about a child playing with tools.

It's more a paradigm than a tool, on the notion of technique and mastery we agree, but not on transparency, as a paradigm they have a huge effect on style and approach; e.g. OOP & Imperative allow side effects, whereas FP does not, the thought process in modelling this is different, but I'm certainly not saying they are mutually exclusive, they definetly not; it's quite normal to have a mixed codebase.

 

[BandwidthAddict]

As for OOP & FP being merely tools, I get the general idea, but it's really not a great analogy especially the part about a child playing with tools.

It's more a paradigm than a tool, on the notion of technique and mastery we agree, but not on transparency, as a paradigm they have a huge effect on style and approach; e.g. OOP & Imperative allow side effects, whereas FP does not, the thought process in modelling this is different, but I'm certainly not saying they are mutually exclusive, they definetly not; it's quite normal to have a mixed codebase.

All tools have a paradigm. Ask a master carpenter about their tools and they would be able to explain. Same for coding. OOP, for example, did not enter this world as a language but as a paradigm to manage state. It started out as an idea for state encapsulation and we see the genesis of the implementation as object based in languages such as C where a mutable structure instance containing state is passed in as a parameter to functions. This encapsulation of state was first enhanced using MACROs then eventually gained direct language support in C++.

Where you have to interact with the world, you have side-effects. Output is a side-effect. That is why all FP implementations are not pure. FP has it's uses and in many respects it is a great tool for simplifying certain code segments.

Same for state. There are programs where you can avoid state but most require manipulation of state. FP as a paradigm doesn't deal with state very well but OOP does.

Using the right tool for the right job is the role of the master.

 

[BandwidthAddict]

Transparency is the ultimate level of expertise where the master instinctually uses the right tool for the job.

It takes years of conscious training to achieve.

 

[rward]

if this is in reference to FP, then remember they're just another function like substr, granted they've been written to be far more flexible and extensible than a average function; but doesn't immediately imply unreadability. Remember the first time any language was created, it's syntax would have been foreign, similarly when new features were introduced like covariance and contravariance, just because you didn't know it, doesn't mean the rest of the team shouldn't use it, or have to litter their code with training wheels (the stuff you should find in function reference).

Initially it was in reference to the numbers you posted but then it became more generalised as sometimes I've found myself writing some ridiculiously ineligible code because 'it's more modern/shorter/whatever'. Refactoring produces different code that may take an extra 0.001 seconds to run but it's a heck of a lot more readable and understandable at a glance.

 

[[)roi(]]

All tools have a paradigm. Ask a master carpenter about their tools and they would be able to explain. Same for coding. OOP, for example, did not enter this world as a language but as a paradigm to manage state. It started out as an idea for state encapsulation and we see the genesis of the implementation as object based in languages such as C where a mutable structure instance containing state is passed in as a parameter to functions. This encapsulation of state was first enhanced using MACROs then eventually gained direct language support in C++.

Let's ask Google... Google... what is a tool?

... a device or implement, held in the hand, a penis??? Really... so that's what you consider OOP and FP to be?

---

How about a paradigm... why not also ask Google... Google... what is a paradigm?

A "a world view underlying the theories and methodology of a particular scientific subject"... certainly sounds more appropriate than a penis

Where you have to interact with the world, you have side-effects. Output is a side-effect. That is why all FP implementations are not pure. FP has it's uses and in many respects it is a great tool for simplifying certain code segments.

Same for state. There are programs where you can avoid state but most require manipulation of state. FP as a paradigm doesn't deal with state very well but OOP does.

Using the right tool for the right job is the role of the master.

Now you are just repeating what I said...

OOP & Imperative allow side effects, whereas FP does not, the thought process in modelling this is different, but I'm certainly not saying they are mutually exclusive, they definetly not; it's quite normal to have a mixed codebase.

Except this "Output is a side-effect"... really?... do you really understand what a side-effect is?

Doesn't this bit: "a secondary, typically undesirable effect" seem a bit odd?

Wait...what do the major universities call this?

Standford:


Cornell:

We could painfully continue this... but really what's the point... I'll stick with my paradigm and you can stick with your penis... err... tool (jokes... forgive me, I couldn't help it).

 

[[)roi(]]

Initially it was in reference to the numbers you posted but then it became more generalised as sometimes I've found myself writing some ridiculiously ineligible code because 'it's more modern/shorter/whatever'. Refactoring produces different code that may take an extra 0.001 seconds to run but it's a heck of a lot more readable and understandable at a glance.

So let me try to understand what you are saying... you think more code is better than less code?? really? Wait let's ask the Internet:

1. What's does Jeff Atwood think? "The Best Code is No Code At All"

It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity.
If you love writing code-- really, truly love to write code-- you'll love it enough to write as little of it as possible.

2. What does Will Shipley think?

I ask you, grasshopper, which is better: flexible code or tiny code?

"Ah," you exclaim, "Learned master, it is a trick question: code which is tiny yet flexible is best!"

WRONG! Tiny code is always best. Now you must carry water up the hill for the rest of the day.

I could go on... but in short you're going to struggle to find support for the notion that more code is better.


Ps... refactoring even happens in FP...

 

[biometrics]

Jeez you guys are way too academic. I've been coding for 30+ years and don't over think things the way you guys do. Probably why I've worked for myself 90% of the time.

 

[[)roi(]]

Jeez you guys are way too academic. I've been coding for 30+ years and don't over think things the way you guys do. Probably why I've worked for myself 90% of the time.

Academic?... really?... is that in reference to the meaning of words?

Also have been coding for a while (>36+ years)... and also self employed.

 

[Thor]

Jesus, puts things into perspective concidering I've been doing PHP for 2 weeks now yet I'm exposed to knowledge and guidance of multi decade programmers here on the forum. It's truly an honor.

 

[biometrics]

Academic?... really?... is that in reference to the meaning of words?

Also have been coding for a while (>36+ years)... and also self employed.

As they say, "never discuss politics, religion, sex or programming languages in polite company".

Do you sell your time or products?

 

[[)roi(]]

As they say, "never discuss politics, religion, sex or programming languages in polite company".

Lol... I was aware of the first three, but the third is just way too much fun... advancement requires debate (never too old to learn) ... and throwing a jab is often just too irresistible .

Do you sell your time or products?

The former; worked for a number of corporates; also tried selling solutions I built; conclusion: far easier to consult.

 

[[)roi(]]

Jesus, puts things into perspective concidering I've been doing PHP for 2 weeks now yet I'm exposed to knowledge and guidance of multi decade programmers here on the forum. It's truly an honor.

We all started from nothing, except that today you have far more resources on hand; in the end it's equalised out, especially if we consider you're far more under the anvil than we were.

 

[Bobbin]

I have no idea which I'm using good thing coding is only a minor hobby for me.

I kind of have a procedural mindset, having started with basic on the C64 many a year ago. I absolutely despise OOP, because you can be a master at syntax but have fkall clue with classes and inheritance and sit and stare at the screen or read for hours trying to figure out how to get something simple done (Spend more time learning to reuse than just DIY). And now we're all talking about functional which to be honest I'd never heard of before.

I guess I'm a procedural hack then at best!

 

[rward]

So let me try to understand what you are saying... you think more code is better than less code?? really? Wait let's ask the Internet:

No, apply some reading comprehension and I'll break it down for you again:

I think that having something that is immediatly legible to the majority of developers out there and is 0.0001 seconds slower is better than having something that would take a google search to figure out.


majority of developers is the key word. Majority of developers can read the for loop first time but didn't know wtf an array_map is until it is explained.


At the same time I did agree that there are cases where 0.0001 seconds do matter and in those cases you aren't employing from the majority of developers, you're employing specialists (and if you're not then you're probably not aware that 0.0001 seconds matter).


The take away is: Quit worrying about if your code is fast enough and get the damn stuff completed. If you're following some general guideline/framework then that should be good enough. When you hit the stage that 0.0001 seconds matter you should have the investment to easily take care of the problems.

 

[[)roi(]]

I have no idea which I'm using good thing coding is only a minor hobby for me.

I kind of have a procedural mindset, having started with basic on the C64 many a year ago. I absolutely despise OOP, because you can be a master at syntax but have fkall clue with classes and inheritance and sit and stare at the screen or read for hours trying to figure out how to get something simple done (Spend more time learning to reuse than just DIY). And now we're all talking about functional which to be honest I'd never heard of before.

I guess I'm a procedural hack then at best!

On FP, here's something I wrote about the difference between and OOP and FP, specifically with regards to function input.

 

[DA-LION-619]

snip.
The take away is: Quit worrying about if your code is fast enough and get the damn stuff completed. If you're following some general guideline/framework then that should be good enough. When you hit the stage that 0.0001 seconds matter you should have the investment to easily take care of the problems.

+1

 

[[)roi(]]

No, apply some reading comprehension and I'll break it down for you again:

I think that having something that is immediatly legible to the majority of developers out there and is 0.0001 seconds slower is better than having something that would take a google search to figure out.


majority of developers is the key word. Majority of developers can read the for loop first time but didn't know wtf an array_map is until it is explained.

Sorry... but that's just wrong; Surely you don't have an internal policy that says:

• "write code that the simpleton in your team can understand?".

As for "The Dumbing Down Of Programming"; there's a fairly well known remark (Barne Stroustrup) that says "Complexity Has To Go Somewhere"; hiding it in the OOP soup doesn't change that.

But don't take my word for it, here the response (question 9) from Bjarne Stroustrup when the same was said about C++.

Complexity has to go somewhere and I think that putting it in the language in the form of direct support of common and powerful techniques is a good idea (or else I wouldn't have done it . Have you seen C code that simulates class hierarchies, parameterized types, or exceptions? Such code tend to be a complete mess of pointers, casts, and macros. In C++, such code can be clean and simple. Most importantly, the constructs have well-specified semantics rather than just comments explaining the intent of code fragments. What has happened is that the complexity has been transferred from the code to the language definition (and compiler).

You are right that there is little need to use all of C++ explicitly in every project. However, that doesn't mean that you need to impose restrictive "gudelines". When did you last use all of Unix or all of NT explicitly on a project? Would you like some manager to tell you exactly which OS facilities you could and couldn't use - independently of the nature of a project?

How is FP any different from this; that complexity has also been added to most of the popular languages? The fact that programmer's don't have to rewrite this is what makes this easy, not only for the programmer's that could have built this themselves but also for the guys that have no clue; all they now need to do is to learn how the functions works, just like they had to do for substring.

Biggest take away; it's less code... and less code is always good, unless of course you're lucky enough to be paid for lines of code (I've got a code generator looking for a job).