On Thursday, 13 January 2022 at 17:57:58 UTC, bauss wrote:
> Basically what you said, as the sane thing is working with pure UTC and just offsetting it by the timezone and only actually accounting for timezone when you need to display the time to some user.

This is a common myth.

It works ok for times in the past, but it drops important information for times in the future.

On Friday, 14 January 2022 at 01:59:19 UTC, Dom DiSc wrote:
> you will learn later that your class is not as totally ordered as you thought at first glance.

enum PartialOrdering { Less, Equal, Greater, Indeterminate }
enum TotalOrdering { Less, Equal, Greater }
interface PartiallyOrdered { PartialOrdering cmp(PartiallyOrdered other); }
interface TotallyOrdered { TotalOrdering cmp(TotallyOrdered other); }

On Fri, Jan 14, 2022 at 01:48:06AM +0000, Dom DiSc via Digitalmars-d wrote: [...]
> > This makes me question the wisdom of putting opCmp in the common base of all classes.  If only a small subset of classes will be comparable with each other
> 
> This is a misunderstanding.
> First of all, you don't compare classes, but objects (instances) of
> the same class.
> And the majority of objects may well be comparable.
[...]

Majority? Hardly.  How should opCmp for std.stdio.File be defined?  What does it even mean for one File to be "less than" another?  What about a Socket?  What about a Widget or Window? What about a ServerConnection? What about an ObjectFactory?  What kind of order can be meaningfully imposed on objects of such classes?

In the universe of things one might want to define classes for, only a narrow subset are meaningfully (partially) orderable.  And among them, an even narrower subset is linearly-orderable (mostly just user-defined numerical types and number-like objects).  Even std.complex.Complex does not have any meaningful order (except for the very narrow case where the imaginary part is zero).

A base class should generally encapsulate functionality common to ALL subclasses.  If most classes are not meaningfully orderable (File, Socket, Widget, Connection, Factory, Complex), then why are we shoehorning opCmp into the base class of ALL classes?


T

-- 
Unix is my IDE. -- Justin Whear

On Friday, 14 January 2022 at 02:22:13 UTC, H. S. Teoh wrote:
> On Fri, Jan 14, 2022 at 01:48:06AM +0000, Dom DiSc via Digitalmars-d wrote: [...]
>> > This makes me question the wisdom of putting opCmp in the common base of all classes.  If only a small subset of classes will be comparable with each other
>> 
>> This is a misunderstanding.
>> First of all, you don't compare classes, but objects (instances) of
>> the same class.
>> And the majority of objects may well be comparable.
> [...]
>
> Majority? Hardly.  How should opCmp for std.stdio.File be defined?
Oh, come on. Every browser need to order files. Of course there are endless different orders (by size, by name, by date, ...) but there IS an order  - and one need to be applied if you want to show the user a list. How else can you create a list other than creating an order?!?

> What does it even mean for one File to be "less than" another?
It means it should be shown before the other one in a list.
And this also makes clear why this order is only partial, because maybe you have some filter. All files filtered out are non-comparable to ones within the list, because they are not shown, neither before nor after. And of course they are not equal.

>  What about a Socket?
Any kind of ID?

> What about a Widget or Window?
z-Order? - at least for windows that really matters.

> What about a ServerConnection?
Priority?

> What about an ObjectFactory?
Nah, maybe for something too generic order doesn't matter so much, but at least for the majority of your examples there were meaningful orders, don't you think?

On Fri, Jan 14, 2022 at 03:04:28AM +0000, Dom DiSc via Digitalmars-d wrote:
> On Friday, 14 January 2022 at 02:22:13 UTC, H. S. Teoh wrote:
[...]
> > Majority? Hardly.  How should opCmp for std.stdio.File be defined?
>
> Oh, come on. Every browser need to order files. Of course there are endless different orders (by size, by name, by date, ...) but there IS an order  - and one need to be applied if you want to show the user a list. How else can you create a list other than creating an order?!?

A File does not have an inherent order; an *directory entry* may have one of several possible orders imposed upon it.  You create a list by defining an external ordering (by name, by date, by size, etc.). The file itself is not inherently orderable, and therefore the ordering does not belong in the class.


> > What does it even mean for one File to be "less than" another?
>
> It means it should be shown before the other one in a list.

Yes, it means "less than" **according to some externally-defined order**. The ordering is external to the file, and not inherent to it. This is why there are multiple possible orders.  Which of them should File.opCmp use?


> And this also makes clear why this order is only partial, because maybe you have some filter. All files filtered out are non-comparable to ones within the list, because they are not shown, neither before nor after. And of course they are not equal.

Your mention of "filter" makes it clear that the order does not belong in the File class; it belongs in another object that represents an entry in a list of files. A filter is something you use to impose an order on a collection of unordered objects; it's not something inherent to the object itself. Therefore, std.stdio.File should not have an .opCmp defined for it.


> >  What about a Socket?
> Any kind of ID?

Again, that's imposing an external order to something that inherently doesn't have one. You can sort a list of sockets by last access time, connection speed, lexicographic IP address, etc., but these are external orders imposed upon the Socket, not an inherent order.


> > What about a Widget or Window?
> z-Order? - at least for windows that really matters.

Also an external order.


> > What about a ServerConnection?
> Priority?

Ditto.


> > What about an ObjectFactory?
> Nah, maybe for something too generic order doesn't matter so much, but at least for the majority of your examples there were meaningful orders, don't you think?

No, they are not inherently orderable, the orderings you mentions are external orders imposed on them.  An external order should be defined by an external predicate that compares two objects (this is why std.algorithm.sort takes a predicate, btw), not in the .opCmp which defines an *inherent* order.  You can order complex numbers by magnitude, for example, but that does not mean they are inherently orderable.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.

On Friday, 14 January 2022 at 03:41:49 UTC, H. S. Teoh wrote:

> No, they are not inherently orderable, the orderings you mentions are external orders imposed on them.
Nothing is inherently ordered. The order is always some new property given to the object in question. Numbers are nothing then a (unordered) set plus an order given to them (an axiom on its own). The order is never "inherent" and there are always endless different ways to assign an order to a set of objects.
The important part is: it is mostly useful to do so (assigning a specific order to a set of objects), thereby making from a set an ordered set.
And especially on computers a set always need at least some "default" order (e.g. address), otherwise you cannot access its elements.
But I agree that it is useful to have a way to assign some predicate to a class by which its instances should be ordered (at least if you don't like the default order: the memory address where it is stored), but that need not be a member function, so I omitted it.