[roeter]

This blueprint proposes to introduce the concept of 'train pools' in timetable mode :
Timetable pools

Example of a pool definition (two storage tracks) :



Example of paths definitions - storage path, access path and train path for train to exit from pool :



Regards,
Rob Roeterdink

[James Ross]

roeter, on 07 March 2017 - 01:56 AM, said:

This blueprint proposes to introduce the concept of 'train pools' in timetable mode :
Timetable pools

The file name in this blueprint of ".pool_or" should be ".pool-or" (or ".timetable-pool-or" to be really good) as hyphens are preferred in file extensions (the timetable extension is similarly "bad" but it's too late to fix that unless we support two extensions).

[roeter]

It's hard to change a habit of a lifetime - I've been using underscores as 'separators' for over 30 years, never used hyphens.
It wouldn't be too difficult to handle both timetable-or and timetable_or definitions, I will look into that.

Regards,
Rob Roeterdink

[Jovet]

James Ross, on 19 March 2017 - 07:32 AM, said:

...as hyphens are preferred in file extensions...

Why?

[James Ross]

Jovet, on 21 March 2017 - 03:21 AM, said:

Why?

I seem to remember seeing it in one of the MSDN guidelines documents, but I haven't been able to find that since; in any case, the examples on e.g. https://msdn.microso...esktop/cc144148 and the ones registered on my computer all point to hyphens:

• .accountpicture-ms
  
• .appcontent-ms
  
• .appref-ms
  
• .bash_login
  
• .bash_logout
  
• .bash_profile
  
• .devicemanifest-ms
  
• .devicemetadata-ms
  
• .dl_
  
• .dtcp-ip
  
• .dvr-ms
  
• .ex_
  
• .in_
  
• .library-ms
  
• .mfcribbon-ms
  
• .ms-one-stub
  
• .ms-windows-store-license
  
• .oc_
  
• .search-ms
  
• .searchConnector-ms
  
• .settingcontent-ms
  
• .sr_
  
• .sy_
  
• .vbox-extpack
  
• .xrm-ms
  
• ._bsln140
  
• ._bsln150
  
• ._sln
  
• ._sln100
  
• ._sln110
  
• ._sln120
  
• ._sln140
  
• ._sln150
  
• ._sln60
  
• ._sln70
  
• ._sln71
  
• ._sln80
  
• ._sln90
  
• ._vbxsln100
  
• ._vbxsln110
  
• ._vbxsln80
  
• ._vbxsln90
  
• ._vcppxsln100
  
• ._vcppxsln110
  
• ._vcppxsln80
  
• ._vcppxsln90
  
• ._vcsxsln100
  
• ._vcsxsln110
  
• ._vcsxsln80
  
• ._vcsxsln90
  
• ._vjsxsln80
  
• ._vpdxsln100
  
• ._vpdxsln110
  
• ._vpdxsln120
  
• ._vstasln80
  
• ._vw8xsln110
  
• ._vwdxsln100
  
• ._vwdxsln110
  
• ._vwdxsln120
  
• ._vwdxsln140
  
• ._vwdxsln150
  
• ._vwdxsln80
  
• ._vwdxsln90
  
• ._vwinxsln120
  
• ._vwinxsln140
  
• ._vwinxsln150
  
• ._wdxsln110
  
• ._wdxsln120
  
• ._wdxsln140
  
• ._wdxsln150

The ones with underscores are either: Linux files (.bash_*) or compressed/backup versions of normal types (.xx_ and ._xxx).

The ones with hyphens are all normal (non-backup, etc.) files, like ".accountpicture-ms" and ".library-ms".

[engmod]

I too have been using _ for 30 years.

We will not be using Microsoft crap in the long term.

The hyphen is for English punctuation.

[Jovet]

James Ross, on 21 March 2017 - 10:00 AM, said:

I seem to remember seeing it in one of the MSDN guidelines documents, but I haven't been able to find that since;

That's utterly ridiculous. It's not Microsoft's business whether someone chooses to use underscores or hyphens in a file extension. Just more example of their inanity. I would hope you would not take such a "recommendation" seriously.

Personally, I do not like either in a file extension. I think file extensions should be short and sweet.

[James Ross]

Jovet, on 21 March 2017 - 01:42 PM, said:

That's utterly ridiculous. It's not Microsoft's business whether someone chooses to use underscores or hyphens in a file extension. Just more example of their inanity. I would hope you would not take such a "recommendation" seriously.

I do not understand your position at all; it's their OS, why would you not expect them to issue some guidance on how to use it? The most prominent stuff is UI/UX (which is backed by years of research and development, and user testing) but I don't see why it shouldn't extend to development stuff - in fact, it can be critically important for apps to stay compatible and not interfere with each other (although not so important in this case).

IIRC their recommendation was to use "type-company" so that the file extension was effectively namespaced to your company, preventing unexpected collisions - which is a real problem when people insist on creating new 3-letter extensions.

I don't know why they chose hyphens. I happen to think hyphens read better than underscores in this case, but above all else it is still just a recommendation. We can follow it or ignore it. My recommendation is to follow their recommendation, though. :)

[Jovet]

James Ross, on 21 March 2017 - 02:10 PM, said:

I do not understand your position at all; it's their OS, why would you not expect them to issue some guidance on how to use it?

Because it's micro-managing. Pun not intended.

Next it will be "recommended" Hungarian notation be used for data filenames, or something like that. It's pretty easy to make a fairly unique file extension (which, of course, do not have to be 3 chars long) without all that overthink. It's a solution for a non-problem. Just like a lot of stuff coming out of Redmond these days.

[cjakeman]

Jovet, on 22 March 2017 - 04:19 AM, said:

Because it's micro-managing.

I don't agree. When we're working together on something complex, we all benefit from things which are tidy and predictable - it saves a lot of time and frustration.

Overall, I think we developers are given a great deal of freedom, but some things are best done "the Open Rails way".

[Jovet]

cjakeman, on 22 March 2017 - 09:05 AM, said:

I don't agree. When we're working together on something complex, we all benefit from things which are tidy and predictable - it saves a lot of time and frustration.
Overall, I think we developers are given a great deal of freedom, but some things are best done "the Open Rails way".

I am sorry if it isn't clear, but my "beef" and comment above is aimed at Microsoft. I think the alleged existence of the "Microsoft recommendation" that James describes above is beyond ridiculous. I haven't been able to find it, though.

I don't have any personal stake in the decisions that actually apply to OR in this matter, but I agree that whatever is decided should be consistent. There definitely should be an "OR-way" of doing things. And it shouldn't be up to Microsoft to micromanage things that aren't widespread problems.

[Lindsayts]

James Ross, on 21 March 2017 - 02:10 PM, said:

I do not understand your position at all; it's their OS, why would you not expect them to issue some guidance on how to use it? The most prominent stuff is UI/UX (which is backed by years of research and development, and user testing) but I don't see why it shouldn't extend to development stuff - in fact, it can be critically important for apps to stay compatible and not interfere with each other (although not so important in this case).

IIRC their recommendation was to use "type-company" so that the file extension was effectively namespaced to your company, preventing unexpected collisions - which is a real problem when people insist on creating new 3-letter extensions.

I don't know why they chose hyphens. I happen to think hyphens read better than underscores in this case, but above all else it is still just a recommendation. We can follow it or ignore it. My recommendation is to follow their recommendation, though. :)

Hopefully, a friendly comment...................

Surely though its not that difficult to parse either an "_" or a "-" as being equivalent, In script files converting text to file names I regularly treat "_" "-" and " " (a space) as indentical, this is trivial in Unix.

This would appear to save a lot of angst.

Important point, while there will be an "openrails way" it would be well to remember everyone here is a volunteer, it is wise to make it as easy as possible for anyone to contribute, this means there does need to be a good deal of flexibility. If one starts giving volunteers orders, one will quickly start losing people.

Lindsay, 30 years serving in a volunteer fire brigade.

[Genma Saotome]

Practicality:

Double click on a string that has hyphens or underscores results in rather differently results in many places (see Windows Explorer for one such example). Using hyphens breaks up the string where underscores do not. My use of Cal-P_Whatever instead of Cal_P_Whatever gives me nothing but grief in many situations... I really don't need/want P_Whatever selected.

As for file suffixes, yeah, occasionally you find two identical suffixes for wholly different file types so adding some sort of company code does make a bit of sense... but hyphens instead of underscores, sorry, cutting the string with hyphens is a royal PITA, everytime.

[roeter]

Let's keep this in proportion.
From a user's viewpoint, it does make sense to have a single rule for naming file extentions. As we start to introduce more and more or-specific files it would not be very helpfull to users if some files require underscores and others require hyphens. There's a lot of sense in setting a single rule. Whether that be hyphen or underscore does not really make a difference - as long as it's always the same. That makes sense. The fact that I did not follow this rule is not because I object to it, but simply because if I sit down and create files or whatever, I use underscores. Point. Nothing else to it : when I start creating new functions, my mind is focused on what is needed for those functions, everything else like naming extentions is done on 'automatic pilot'.
So closing off : the documentation will follow the official line and define hyphen only, the progam however, for both timetable-or and pool-or, will process both.

Regards,
Rob Roeterdink

[James Ross]

Lindsayts, on 22 March 2017 - 02:37 PM, said:

Surely though its not that difficult to parse either an "_" or a "-" as being equivalent, In script files converting text to file names I regularly treat "_" "-" and " " (a space) as indentical, this is trivial in Unix.

It's easier inside files than in filenames as (at least in Windows and .NET APIs) you will ask for files matching a basic glob pattern, which doesn't support such equivalences. Nevertheless, it isn't hard to do.

Lindsayts, on 22 March 2017 - 02:37 PM, said:

Important point, while there will be an "openrails way" it would be well to remember everyone here is a volunteer, it is wise to make it as easy as possible for anyone to contribute, this means there does need to be a good deal of flexibility. If one starts giving volunteers orders, one will quickly start losing people.

I've only been recommending it, and Rob's been kind enough to go with that recommendation.