[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]

[Burichan] [Futaba] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PNG
  • Maximum file size allowed is 10240 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

No.34078  

В каком скриптовом языке, пригодном для разработки веб-приложений можно имплементировать интерфейс после инициализации класса? Я перейду на него. Меня заебал этот php. Впрочем, похуй на интерфейсы. Они физически не могут гарантировать того, что в них вкладывается. Наличие функции с заданным именем? И что? Оно все равно ничего не гарантирует. Гарантировать могут только тесты. Дойдет до того, что вместо интерфейсов я буду определять в классе константу IMPLEMENTS_INTERFACE_AutoloadableClassLoader_f05d922c5263491d853d8afbc64508cf и это будет в сто раз удобнее чем то убожество, которое я имею сейчас когда classloader implements interface[a-Z]+ но, блядь, чтобы он загрузился, нужно сначала загрузить все его интерфейсы, либо не писать implements в то время как он действительно implements. Ну что за говно? Как быть? Что делать? Ебаныврот.джпг.
Разрабочик очередного нахуй никому не нужного и неизвестного фреймворка на php

>> No.34081  

Ruby просьба не предлагать. Язык быть может и хороший (я на нем небольшое консольное приложение написал), но трупешник. Нет поддержки apache, нет поддержки cgi. Какой-то свой уёбищный веб-сервер (нахуй он мне сдался-то когда у меня на всех хостах апач стоит) и навязывание рельсов загонят его в ёбаную могилу.
ОП

>> No.34082  

В своем ёбаном фреймворке, блеядь, я буду использовать тесты вместо зафейленых разработчиками php интерфейсов. Снизошло на меня просветление. Ёбаный php. Хотя по-хорошему мне следовало бы написать свой язык. Сраное проклятое говно. Все приходится вечно делать самому, как же это достало.
ОП

>> No.34086  
File: 1276341510144.jpg -(151677 B, 826x500) Thumbnail displayed, click image for full size.
151677
>> No.34088  

>>34078 А чем существующие фреймворки, тот же ZF для php не устраивают, например?

>> No.34093  

>>34086
Что бы ты понимал, мудило пиздоглазое.

>>34088
Они уёбищные, все как один. В детализации:

  • Сложные/запутанные. Изучение фреймворка напоминает изучение нового ЯП.
  • Создавать приложение на их основе занимает слишком много времени.

Единственный их плюс - облегчение поддержки приложения. Из популярных пробовал изучать CodeIgniter и ZF и еще поверхностно пару %уже не помню названий%. После часа изучения хотелось вырвать его создателям глаза. В первом случае - он слишком морально устарел, во втором - меня просто заебало перерабатывать все новую и новую информацию и доков. Фреймворк - всего лишь методика структуризации программного кода. Каркас на который "клеится" программный код самого приложения. Он, блядь, не должен быть сложным. Он, блядь, должен быть простым как молоток. Сейчас я постепенно понимаю, что все эти изъебства и запутанности в них порождает убогость самого языка. В случае с Ruby - близорукость его создателей, как ни странно.

>> No.34094  

>>34093

> и доков
> из доков, твоюмать.

selffix

>> No.34096  
File: 1276351756376.jpg -(906695 B, 800x928) Thumbnail displayed, click image for full size.
906695
> я на нем небольшое консольное приложение написал
> Нет поддержки apache, нет поддержки cgi

Orly?
Cgi это просто интерфейс взаимодействия веб сервера и веб приложения, реализовать его можно на чем угодно, хоть на brainfucke, главное чтобы программа могла выводить в stdout документ нужного формата с соответствующими заголовками, и если требуется интерактивность то хотябы читать stdin или аргументы запуска.

>> No.34101  

>>34096
Ок, попробую еще раз разобраться как запустить эту штуку. Насчет поддержки Apache - mod_ruby, который по определению быстрее cgi и fastcgi последний раз обновлялся в 2008 и, как я понимаю, издох.

>> No.34102  

>>34078

>имплементировать интерфейс после инициализации класса

Что такое "инициализация класса"? Может, создание объекта? Или декларация/определение(для пхп декларация и определение походу едины) класса? Так или иначе, зачем тебе может понадобиться возможность реализовывать интерфейс после определения класса? (если уж такая возможность понадобилась, сразу видится решение в создании нового класса, который либо включает объект првоначального и реализует нужный дополнительный интерфейс, либо вариант с наследованием класса и одновременной реализацией нужного интерфейса. На выходе у тебя будет нужный класс с реализованным интерфейсом). А то, что ты говоришь, технически не осуществимо (по крайней мере в статически-типизированных языках, а про пхп точно сказать не могу, конечно) и нелепо - возможность безконтрольно динамически модифицировать тип рушит всю типизацию и то, зачем все создавалось. (Хотя касаемо пхп точно сказать не могу, с ним, слава Богу, пока не пришлось работать)

>Гарантировать могут только тесты

О каких тестах идет речь?

>остальное

Скажи, какая перед тобой стоит задача и что ты хочешь сделать? Отделить реализацию от интерфейса?

>> No.34108  

>>34102
Фреймворк состоит из пакетов. Пакеты делятся на выражающие собой какие-либо принципы (напр. единая точка входа в приложение, автозагрузка классов, ленивая загрузка классов пакета) и имплементацию этих, либо других принципов, в конкретном данном случае имеется в виду принцип автозагрузки классов.
В (условно) index.php я через require_once загружаю понравившийся мне пакет с classloader'ом и импортирую в него через $classloader->importPackages(array $packages) все остальные пакеты, которые могут мне потребоваться. Одно из условий использования classloader'a, который я загружаю - в том, чтобы все пакеты которые могут потребоваться обязательно прописывались ручками в importPackages. Это нужно для того чтобы при взгляде на index.php можно было понять с каким приложением имеешь дело. Например, используется ли единая точка входа и autoloading.
Проблема в том, что сам classloader имплементирует пакет classloader_autoloadable, который должен быть загружен до загрузки пакета с classloader'ом, а пакет classloader_autoloadable имплементирует стандарт описания пакета. В итоге вместо использования ленивого импорта пакетов через classloader я должен ручками прописывать require_once пакетов, которые попали в зависимость друг от друга, да еще и соблюдая порядок этих зависимостей, что и вызывает у меня лютый butthurt. Если же classloader не будет имплементировать classloader_autoloadable, то это будет сраная идеологически некорректная недоделка. Вот если бы classloader смог загрузиться, зарегистрировать себя через register_autoload(), а затем загрузить пакет classloader_autoloadable и прописать что он имплементирует этот пакет, проблема бы была решена. Надеюсь достаточно последовательно изложил происходящее.

> О каких тестах идет речь?

О юнит тестах, иначе:
function loadClass($className)
{
exit("Соси хуй, быдло. Твой интерфейс не может проверить ни правильность исполнения кода, ни даже возвращающееся значение. Впрочем, если тебя устроит одно лишь формальное совпадение имен функций в классах, то можешь пилить свои интерфейсы дальше, уёбок.");
}

>> No.34112  

>>34108
Такое ощущение, что ты просто что-то делаешь не так. Посмотри, как реализуются аналогичные функции в других фреймверках. Ничего тебе посоветовать не могу, ибо пхп не знаю.

Как насчет Java?

>> No.34114  

>>34112

> Посмотри, как реализуются аналогичные функции в других фреймверках.

Боюсь что перед ними подобных идеологических задач даже не ставится. В Codeigniter, View - это просто phtml файл. Без вариантов. Fail.

> Как насчет Java?

Красноглазие и конпеляция? В php - открыл файл, поправил код, готово.

>> No.34117  

>>34114

> конпеляция?

Ты говоришь это так, словно в этом есть что-то плохое.

>> No.34120  

>>34117
Это неудобно же.

>> No.34123  

>>34120
Исключительно дело привычки. В крайнем случае можно настроить любимый текстовый редактор так, чтобы он делал make после каждого сохранения, тогда ты разницы и не почувствуешь даже.

>> No.34129  

стоит еще добавить, что при компиляции обнаруживаются многие глупые ошибки, которые сложно было бы найти (во всяком случае дольше было бы искать) не будь ее (компиляции).

>> No.34131  

>>34129
Возможно ты в чем-то прав.

>> No.34155  
File: 1276372578568.png -(24187 B, 135x128) Thumbnail displayed, click image for full size.
24187

Haskell
%%похуй, что не скриптовый%%



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]