Как называть модули?

[Mirage]

Спор о чем конкректно???

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

[Лекс Айрин]

Насчет середины - не могу представить за каким хреном системе логирования знать что она логирует. Куда и как да, знать должна.

Вообще-то названия для программиста, а не для программы. Поэтому функции/классу/модулю нет смысла знать. А программисту очень полезно.

А вот точку в имени файла я бы не стал применять ни при каких условиях. Случайно вставите пробел перед нею и доооолго будете думать в чем косяк. Особенно если прогу придется собирать под линухой.

[Sharfik]

Господа, вот читаю... и, "то ли лыжи не едут, то ли я....очень странный"
Кто-то любит зеленое, кто-то - стриженое...
Спор о чем конкректно??? Хочется всеобщей унификации или ?

"Каждый выбирает по себе..." (с)

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

@hinst,
http://ru.wikipedia.org/wiki/Subst

Хорошая идея.

[Mirage]

Вообще-то названия для программиста, а не для программы. Поэтому функции/классу/модулю нет смысла знать. А программисту очень полезно.

Если в названии модуля логирования упоминается сущность, которую предполагается логировать, значит реализация данного модуля каким-то образом заточена под эту сущность. Что мне и показалось странным, ибо что там затачивать?

А вот точку в имени файла я бы не стал применять ни при каких условиях. Случайно вставите пробел перед нею и доооолго будете думать в чем косяк. Особенно если прогу придется собирать под линухой.

Можно дооолго думать, а можно попробовать таки откомпилировать и компилятор покажет ошибку.

[hinst]

так всё таки можно как-нибудь сделать чтобы в одном проекте было два модуля с одинаковыми именами но в разных папках? Чтобы как-нибудь изощриться, но не слишком мазахично

[Лекс Айрин]

Что мне и показалось странным, ибо что там затачивать?

мало ли... может быть подробность вывода, а может быть и данные опускаемые логером. Файлы по которым надо распихивать определенные данные, эхо на экран/принтер, условия включения/выключения логера. Формат входных/выходных данных.

а можно попробовать таки откомпилировать и компилятор покажет ошибку.

И выдаст вам кучу странных ошибок о не найденных файлах. Причем, часть системных. Это если таких файлов нету в природе... а если (совершенно случайно) есть? может ведь и проглотить. А под линуксом часть файлов окажется скрытой. Нет смысла лишний раз заморачиваться.

[hinst]

Кстати вот какой ещё вариант придумал:
Одна библиотека - один модуль, но в ней сделать под-модули вот как-то так:

Код: Выделить всё

unit Voicer;
interface
  {$Define face}
  {$Include Meow.inc}
  {$INclude Moo.inc}
  ....
  {$Include Bark.inc}
  [$Undef face}
implementation
  {$Define impl}
  {$Include Meow.inc}
  {$Include Moo.inc}
  ...
  {$Include Bark.inc}
  {$Undef impl}
end.


... ну вы поняли. Include-файлов могут быть сколько угодно с одинаковым названием в одном проекте. И ищутся они в ближайшей папке. Так что, Meow.inc может быть в каждой библиотеке свой. Такой подход с include-файлами решает проблему того, что внутренние под-модули библиотеки должны иметь одинаковые имена. Однако, порождает две другие проблемы: каждый раз будут компилироваться все модули, даже те, которые может быть и не нужны. И во-вторых это усложняет, получается стрёмно, ну я думаю понятно, с этими include-файлами, в общем там есть причины по которым это может быть не так удобно, как unit-ы.

[Mirage]

мало ли... может быть подробность вывода, а может быть и данные опускаемые логером. Файлы по которым надо распихивать определенные данные, эхо на экран/принтер, условия включения/выключения логера. Формат входных/выходных данных.

Все же лучше думать и выбирать приемлемые абстракции, нежели так делать.

И выдаст вам кучу странных ошибок о не найденных файлах. Причем, часть системных. Это если таких файлов нету в природе... а если (совершенно случайно) есть? может ведь и проглотить. А под линуксом часть файлов окажется скрытой. Нет смысла лишний раз заморачиваться.

Давайте по порядку:
1. ошиблись в названии модуля в uses (причем тут точка в названии?) - получили ошибку (одну) именно в том месте.
2. ошиблись в наименовании самого файла (причем тут точка в названии?) - обратно, получили ошибку (по кол-ву использований) в местах использования.
Что странного?
Если файл случайно есть, то вряд ли он скомпилируется ведь верно?

Кстати вот какой ещё вариант придумал:

Это не под-модули, это инклуды, как в С. А там нет модулей. И вот тут действительно можно странные эффекты получить, ибо сложно сказать какой инклуд возьмет компилятор.
Инклуды - для исключительных случаев. Когда без них никак.
А тут проблема высосана из пальца.

[Лекс Айрин]

Все же лучше думать и выбирать приемлемые абстракции, нежели так делать.

Кто знает как лучше...

1. ошиблись в названии модуля в uses...

Вообще-то, в случае пробела, две. (так как получилось два модуля). Правда, тут компилятор ругнется на отсутствующую запятую, поэтому ее исправить легко.

2. ошиблись в наименовании самого файла (причем тут точка в названии?)...

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

Если файл случайно есть, то вряд ли он скомпилируется ведь верно?

Не факт. Он ведь может быть и вполне нормальным исходником. В том числе и системным.

[zub]

А другие используют систему именования, похожую на адреса сайтов, только наоборот:
org.glscene.vector

Эта фича работает только на подключение юнитов или для разрешения конфликтов имен тоже?
намтимер

Код: Выделить всё

...
uses
  org.glscene.vector,
  some.lib.vector;
...
var
  MyVector1:org.glscene.vector.TVector;
  MyVector2:some.lib.TVector;
...


?

[SSerge]

imho, без какой либо особой разницы, как их называть. Но - однозначно, недопустимо оставлять базовые дефолтные имена редактора типа project1, unit1, unit и т.д.

[Дож]

@Дож насколько я понимаю, это как раз и значит, что компилятор будет искать файл в папке org в подпапке a в подпапке b файл и именем c.pas. В Java примерно так же, название пакета должно отражать структуру каталогов.

Код: Выделить всё

[doj@korica ~/temp/units]$ mkdir a
[doj@korica ~/temp/units]$ mkdir b
[doj@korica ~/temp/units]$ echo "unit foo; interface implementation initialization Writeln('FOO'); end;" > a/foo.pas
[doj@korica ~/temp/units]$ echo "unit foo; interface implementation initialization Writeln('BAR'); end;" > b/foo.pas
[doj@korica ~/temp/units]$ cat > prog.pas <<-EOF
> uses a.foo, b.foo;
>
> begin
> end.
> EOF
[doj@korica ~/temp/units]$ fpc prog.pas
prog.pas(1,6) Fatal: Can't find unit a.foo used by Program
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode
[doj@korica ~/temp/units]$ fpc -Fu. prog.pas
prog.pas(1,6) Fatal: Can't find unit a.foo used by Program
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode
[doj@korica ~/temp/units]$ fpc -iV
2.7.1


Что я делаю не так?

[sign]

Что я делаю не так?

А вы делайте так:

Добавлено спустя 7 минут 37 секунд:
Или вот так,

[Дож]

А вы делайте так:

И где тут компилятор сам ищет в папках u1 и u2?

Код: Выделить всё

[doj@korica ~/temp/units]$ cat a/foo.pas
unit a.foo; interface implementation initialization Writeln('FOO'); end;
[doj@korica ~/temp/units]$ cat b/foo.pas
unit b.foo; interface implementation initialization Writeln('BAR'); end;
[doj@korica ~/temp/units]$ fpc prog.pas
prog.pas(1,6) Fatal: Can't find unit a.foo used by Program
Fatal: Compilation aborted
Error: /usr/local/bin/ppc386 returned an error exitcode


[hinst]

в общем в самом деле
модуль unit a.b.c
это файл a.b.c.pas
а не файл a/b/c.pas
Я почему-то думал, что в Delphi как пакеты в Java сделали, но не сделали. Ошибся в общем
http://docs.embarcadero.com/products/ra ... s_xml.html
Так что в интерпретации Delphi получается что эта их фича с именами модулей через точку совершенно бесполезна, с тем же успехом можно делать имена модулей через подчёркивание типа a_b_c, никаких улучшений вариант a.b.c не даёт