Web development in 2023

Outlander

I had to Google the "readonly" stipulation. What realistic (or even atypical) case scenarios can you provide that warrants its explicit use?

Never did "cast" variables ie. string, int, boolean, etc. Didn't see the need to do so if everything it interacts with can handle errors/unexpected inputs, be they common or rare, properly.

Edit: with the exception of certain required internal functions, however in this manner:

function FormHandler( $prefill = array() ) { /* */ }

I'd much rather a default function-level based "error handling" (ie. not integer detected therefore, perform this) than a top level PHP error that breaks whatever the user is doing (and often the site or at least the specific action page in the process).

Michael

I had to Google the "readonly" stipulation. What realistic (or even atypical) case scenarios can you provide that warrants its explicit use? — Outlander

You might want to get the name after creating the object.

New way:

class Person
{
  public function __construct(public readonly string $name) {}
}

$person = new Person('Michael');

echo $person->name;

Old way:

class Person
{
  protected $name;
  public function __construct($name)
  {
    $this-name = $name;
  }
  public function getName()
  {
    return $this->name;
  }
}

$person = new Person('Michael');

echo $person->getName();

I'd much rather a default function-level based "error handling" (ie. not integer detected therefore, perform this) than a top level PHP error that breaks whatever the user is doing (and often the site or at least the specific action page in the process).

They're optional. But it's to enforce good coding. If you're expecting an integer then you should write your code such that you only ever give it an integer. If at some point a string is being passed then you've coded it wrong. Strict typing ensures that these mistakes are picked up in development.

Jamal

Strict typing ensures that these mistakes are picked up in development. — Michael

I've only recently started back with statically typed languages after a couple of decades of freedom, and it's been good. It does encourage good coding and it does allow you to fix stuff more easily.

Outlander

— Michael

class Person
{
  protected $name;
  public function __construct($name)
  {
    $this-name = $name;
  }
  public function getName()
  {
    return $this->name;
  }
}

$person = new Person('Michael');

echo $person->getName()

;

No different than

class Person
{
    function __construct( $name ) { $this->name = $name; }
}

$person = new Person( 'Michael' );

echo $person->name;

Is it? Not on my end at least.

Michael

↪Outlander

That allows for public reassignment.

$person->name = 'Mike';

Often times you don't want that which is why such properties are usually protected or private.

Perhaps a better example would be:

class Person
{
  public readonly string $initials;
  public function __construct(
    public readonly string $first_name,
    public readonly string $surname,
  )
  {
    $this->initials = substr($first_name, 0, 1) . substr($surname, 0, 1);
  }
}

$person = new Person('John Smith');

echo $person->initials;

Outlander

Often times you don't want that which is why such properties are usually protected or private. — Michael

Doesn't one generally not "publicly" reassign variables from a helper/framework class?

Say I'm incorporating your framework into whatever PHP project I'm working on. I'd have $myclass and $yourclass, respectively. What reasons would someone who is clearly not "public", as in a full on admin level code editor, edit a property of another class? It can't be for some "security exploit" since they have the full code and could just edit it from the parent class.

If they choose to break the code, even unintentionally, perhaps they shouldn't even be coding in the first place.

What I mean is for example, I use Twilio, a well-known telecommunications framework.

So I could have a thousand different variables going on that range from different classes and functions ($appOne, $appTwo, $functionOne, etc) and there will still be only one "helper" or "external" class. Say in this case $twilio.

So there's no reason to randomly change an independent variable that corresponds to a new class or object just to do so.

Say there is an important object I want to re-use I could just use one line of code to "store" it, statically or dynamically with a "&="

$importantInfo = $twilio->importantInfo;

There would be no reason for me to manually code/reassign at the top level (meaning I literally can access anything) the following

$twilio->importantInfo = 'something that breaks the script';

That would be asinine and utterly intentional. If I can access the parent code I can easily change anything about it anyhow.

Am I making sense? I swear I know what I'm talking about, I'm not trying to be difficult or whatever.

Michael

↪Outlander

That's the entire purpose of things like public, protected, private, readonly, final, typing, interfaces, abstract, etc; to ensure that developers do things properly.

If they choose to break the code, even unintentionally, perhaps they shouldn't even be coding in the first place. — Outlander

In reality things aren't this simple. People are fallible, we forget things and get tired. And especially with open source software, not every contributor is going to immediately know everything about every function and class and whatever. Being able to see at a glance 'protected "name"' immediately tells them that they're not supposed to do '$class->name = 'foo'''.

Think of it as inline documentation with automatic error checking.

Outlander

That's the entire purpose of things like public, protected, private, readonly, final, typing, interfaces, abstract, etc; to ensure that developers do things properly. — Michael

Yeah, sure. Again just trying to better understand not to argue purely for the sake of doing so, but- actually no I get it, especially the latter comment. I'm not an "open source" guy so I'm sure you understand my "that's a solution in search of a problem" mindset. Myself, and many others have gone through painstaking measures in attempt to facilitate HTML based interfaces can perform any reasonable, common-use coding in and of itself, perhaps replacing the need to code altogether.

Being able to see at a glance 'protected "name"' immediately tells them that they're not supposed to do '$class->name = 'foo'''. — Michael

I get that completely. But just to ponder. As a hypothetical. Couldn't all that be resolved by using a simple prefix to the variable? Example (and I do this in mine, sometimes, as do others) ... let's use your WTFramework.

Any common variable a person would use $name, $id, $session, $user, etc.... whatever it is...

Instead use a prefix so it would be

$_name or $wtf_name

literally

$class->_reservedVariable;
$class->wtf_variable;

So no person would ever overwrite a variable in virtually 100% of use cases whatsoever.

I do get the point you want people in an open source framework to access and adjust variables and in a modern PHP dev environment the inline warnings are very useful.

Anyway, nice meeting a fellow coder on here.

Seriously I think TPF or even the two of us should have an old fashioned "code off".

Say a simple guestbook. A page of static content anonymous users can post comments on, sans db, stored as text files. I think that would be interesting. If you have the time.

Michael

Instead use a prefix so it would be

$_name — Outlander

That used to be how things were done, but then PHP introduced "protected" and "private" visibility precisely so that we didn't have to do this.

Outlander

That used to be how things were done, but then PHP introduced "protected" and "private" visibility precisely so that we didn't have to do this. — Michael

But, and correct me if I'm wrong, doesn't that simply put/shift the onus onto the lower developer to use quirky/prefixed variables now?

Example, in running your code, I just got a fatal runtime error "unable to access protected property Person::$name ".

So it's not like it actually frees up the use of the literal verbose name of the variable itself. It just makes it so "Ok now I have to use use '$name2' or '$variable2' instead of what comes firsthand in mind." as far as secondhand development/utilization of a framework goes.

Michael

So it's not like it actually frees up the use of the literal verbose name of the variable itself. It just makes it so "Ok now I have to use use '$name2' or '$variable2' instead of what comes firsthand in mind." as far as secondhand development/utilization of a framework goes. — Outlander

No, it means you're not allowed to change the name.

Outlander

No, it means you're not allowed to change the name. — Michael

So you would agree it is more of a safety net for inexperienced coders versus an actual, functional progression in and of PHP itself. If I want to intentionally change the name, variable, or anything for that matter, of an open source framework I dang will do so from the source code seeing as it's free and open for me to do so if desired.

Web development in 2023

Welcome to The Philosophy Forum!

Categories

More Discussions