Req #80722 [Com]: Missing support for Dependency Inversion Principle and for serving the purpose

From: Date: Wed, 10 Feb 2021 18:53:30 +0000
Subject: Req #80722 [Com]: Missing support for Dependency Inversion Principle and for serving the purpose
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-232043@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80722&edit=1

 ID:                 80722
 Comment by:         rowan dot collins at gmail dot com
 Reported by:        fakhar_anwar123 at hotmail dot com
 Summary:            Missing support for Dependency Inversion Principle
                     and for serving the purpose
 Status:             Suspended
 Type:               Feature/Change Request
 Package:            *Extensibility Functions
 Operating System:   All
 PHP Version:        8.0.2
 Block user comment: N
 Private report:     N

 New Comment:

Firstly, please understand that what you are asking for is not a day's work for someone to add
an extra function, it's a complex feature with wide consequences. Understand, too, that unless
you're offering to pay, you're asking someone to volunteer that effort. 

Using words like "must" and "key feature" come across as a *demand* for that
work; people generally respond better if you can word it as a *suggestion* using words like
"could" and "useful". It's also good to spend some time understanding the
project, and not making basic mistakes like requesting a feature in 8.0 (already released) rather
than 8.1 (where new features will be added to release at the end of this year).

Now, let's try to understand what you're suggesting. Here's what PHP supports
regarding interfaces:

* Defining interfaces
* Marking classes as implementing those interfaces
* Checking manually that a particular value implements a required interface (e.g. using instanceof) 
* Checking _automatically_ that a value implements a required interface (by specifying the interface
as a parameter, return, or property type)
* Documenting the *intent* of interacting with a particular interface in an easily machine-readable
way

The only thing PHP does *not* do is *enforce* the restriction of interacting *only* with the methods
guaranteed by the interface. I think that's what you're asking for.

That's because PHP implements something called "duck typing": if you ask an object to
perform an action, PHP will just check if the object *can* do it, not whether it "should"
according to some contract. This is part of a wider design decision that PHP's type system is
"dynamic": the operations available depend at run time on the type of a particular value,
rather than being guaranteed at compile time by static information.

That fundamental design is unlikely to change, although features have been added in recent versions
making the type system stricter in various ways.

The more checks we add every time the code runs, the slower things will get, so the best time to
check if code is using only the methods promised by an interface would be during static analysis.
Unlike some dynamic languages (e.g. Python, Hack) PHP doesn't currently have an official static
analyser, but there are several very powerful third-party tools that can do these kinds of checks,
e.g. Phan, Psalm. IDEs such as PhpStorm also have built-in static analysis which will enforce this
for you.

If you are really interested in having more functionality around this in PHP, I recommend learning a
bit about how PHP's type system currently works, and what those third-party tools do, and
coming up with an approach that you think would make sense for PHP. That doesn't mean you need
to develop it by yourself, but the more effort you can put into designing it, the more likely you
are to find a volunteer to help you implement it.


Previous Comments:
------------------------------------------------------------------------
[2021-02-08 13:03:09] cmb@php.net

I really don't understand what this feature request is about.  Are
you looking for typed local variables?

------------------------------------------------------------------------
[2021-02-07 12:49:29] fakhar_anwar123 at hotmail dot com

Thanks for providing the link to the guidelines to RFC Process.

what i conclude from the second paragraph in that is that if i do not code a PHP feature myself
using C++ (or, no one choose to develop that feature), then highlighted feature would not become the
part PHP. 

Based on that premise, I hope someone look into the required feature which i am highlighting here. 

If you can do that i will be happy, if not then at least encourage to get the support of that
feature to make PHP stronger platform. (Be eralistic and do not shelter what is missing, lets be
realistic). 

Lets do it, before others highlight this very basic feature as mising in PHP.

------------------------------------------------------------------------
[2021-02-07 12:29:44] rtrtrtrtrt at dfdfdfdf dot dfd35

> When we ask for support of a feature, 
> it should be taken as a support for the 
> platform (PHP), not criticism

for the sake of god: https://wiki.php.net/rfc/howto

------------------------------------------------------------------------
[2021-02-07 12:27:29] fakhar_anwar123 at hotmail dot com

Refined Concept: Uptil PHP8.0, PHP does not support "Interface Variables" which allows to
comply with two core Principles of Software Development
A) Dependency Inversion Principle DIP, and
B) Interface Segregation Principle (ISP)
(These are principles

Why Interface Variables Are Need Feature:
The "Interface Segregation Principle (ISP)" is not just about breaking down larger
interface into smaller interfaces, its actual purpose is to expose/offer (to the Consumers
client-class code) different subsets of the functions of a Serving-entity (Class), in the form of
small Packages / Deals (aka Interfaces)

(...hiding the Mechanism; details of how those Services are produced, internally, by the
Serving-entity)

Consumers (Client-side code) can then consume needed subset/s of functions/services of the Serving
Entity; Class in the form of packages / deals (Interfaces).

Benefit / Purpose:
The Serving-end can extend services of a package (Interface), if needed, without effecting other
exposed Packages (Interfaces) which means without effecting the Consumers consuming those packages
(Interfaces).

Example:
See P-15 and P-13 for better understanding.
https://www.codeproject.com/Articles/18743/Interfaces-in-C-For-Beginners

------------------------------------------------------------------------
[2021-02-07 12:23:25] fakhar_anwar123 at hotmail dot com

Ahh okay so are a user, i assumed you are a C++ developer behind PHP.

My brother i have submitted a strong case along with proper references. But the speed of your
respnse clearly shows that you are in haste and not reading thoroughly. 

When we ask for support of a feature, it should be taken as a support for the platform (PHP), not
criticism.


I am an architect with 20 years experience in Object-oriente Design, and a critical analytical
researcher, technology analyst.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=80722


--
Edit this bug report at https://bugs.php.net/bug.php?id=80722&edit=1


Thread (16 messages)

« previous php.bugs (#232043) next »