Req #81203 [Wfx]: [ FEATURE ] StructType like interface for arrays

Edit report at https://bugs.php.net/bug.php?id=81203&edit=1 ID: 81203 Updated by: requinix@php.net Reported by: 6562680 at gmail dot com Summary: [ FEATURE ] StructType like interface for arrays Status: Wont fix Type: Feature/Change Request Package: *General Issues Operating System: Win10 PHP Version: Irrelevant -Block user comment: No +Block user comment: Yes Private report: N New Comment: Locking before Harald shows up again. Generics and read-only properties are reasonable and have, at one time or another, been discussed and proposed. Needed/child classes don't mean anything. Decorators and dependency injection are design patterns, not language features. Structs are arrays. PHP has no less than three serialization solutions, while its sanitization and validation extension cannot handle application-specific structures and strategies. A complex suite of tools to validate data needs more time and attention than PHP core developers can give it, thus it should be a userland solution. Feel free to spearhead the creation of that library. Previous Comments: ------------------------------------------------------------------------ [2021-06-28 08:52:48] 6562680 at gmail dot com I understand that - php is a language. Language with - no generics - no readonly props - no class nesting - no decorators - no dependency injector - no structs - no, but ok - no serializer/validator inside It seems to really STANDARD things in 2021. Like patterns. In this PROGRAMMING LANGUAGE user MUST ignore readonly and create public methods, because PHP devs likes to speak instead of getting answer in the mind at mondays meetup. Its just an example, and today when i understand how this things required - am sure it should be language things, no framework can change class nesting behavior or property readability - we need \ReflectionClass everywhere cause of "this is a language" And ignore languge and use another cause of "its language". Ok, community could just ignore it, and we have no concurrency now... and NO DAMN HELP. ------------------------------------------------------------------------ [2021-06-28 05:50:10] rtrtrtrtrt at dfdfdfdf dot dfd well, you sound like ab eginner, otherwise you would have framework solutions written in the past years and not start always from scratch or use existing frameworks anyways, PHP is a PROGRAMMING LANGUAGE and not a framework ------------------------------------------------------------------------ [2021-06-28 00:23:44] 6562680 at gmail dot com No, i suppose my problem is realistic position, where the education is almost down and war is incoming, and i try to solve task alone with 2 guys, because new ones becomes more stupid that few years ago. 50% agried of php, 30% beginners, 15% strong juniors, 4% married middles who wont work 1hour over, 1% senior that can handle own blog but still cant help, and noone can explain why he's doing that way. and i see it that last 10 years. "My problem is-guy" Nobody from community ask me to learn or something. Everybody goes conferences to be the star. Nobody wants to code, everybody wants to hype. World is dying, you cant still "ask the community", you have no community for now. ------------------------------------------------------------------------ [2021-06-27 22:40:05] rtrtrtrtrt at dfdfdfdf dot dfd your problem is that you confuse programming language with framework ------------------------------------------------------------------------ [2021-06-27 22:18:53] 6562680 at gmail dot com Main thing of this request is ask you guys to implement type that allows match some object without creating class and implementing interface. Interface segregation is about SERVICE layer, datalayer always has a problem with damn extend/composite. Correct library should have enough objects to be published, but almost all the projects needs to be written faster. Language should give options to write faster. Generics allows to skip code generation - i need to write code generator every project to just generate damn entities by database for doctrine/eloquent + repositories + so on stuff cause of you, guys can't just create syntax like: ``` $repo = $entityManager->getRepo<EntityClass>(EntityClass); ``` i always need to create some phpdoc stuff /** @var EntityClass $repo */ or even create adapter class. Class nesting allows to reduce size of dependency injection layer - declined long time ago, currently i need to create factory with public methods everywhere Readonly props reduces count of public setters - there is no thing Structs allows to use global objects without mappers and without creating tonns of classes. It works like your typehinting where you define "string" - it maps any type to your and check it is possible (Interfaces cannot do that! It is required on DAL layer every second!!!) Decorators allows to configure dependency injector directly in your class and also allows to configure even router BEFORE call the method and allows to collect it by class reflection. - Currently we install Doctrine AnnotationReader (if you see how its realised - you prefer the death) - everytime... You have to ignore requests to create arrow syntax to launch functions and think about how make language EASIER TO WRITE, not MORE FEATURED. As i see your main idea - give community opportunity to solve anything as they want - creates anti-patterns, pseudo-patterns, "experts" and "bloggers" - but really we wont to create CRM in several people - we need damn team cause of tonns of symbols we need to print in IDE. Thank you. ------------------------------------------------------------------------ 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=81203 -- Edit this bug report at https://bugs.php.net/bug.php?id=81203&edit=1