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

From: Date: Mon, 28 Jun 2021 08:52:48 +0000
Subject: Req #81203 [Wfx]: [ FEATURE ] StructType like interface for arrays
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-234659@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81203&edit=1 ID: 81203 User updated by: 6562680 at gmail dot com 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: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2021-06-27 20:57:41] requinix@php.net I can't tell what this "struct" thing is supposed to be, but the bulk of what you wrote (as far as I could understand it) pertains to validation. Data validation is not a job that should be performed by the PHP language itself, and there are plenty of frameworks and libraries and design patterns that can handle the job. ------------------------------------------------------------------------ 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

« previous php.bugs (#234659) next »