Author Topic: Windows - Command line and Dialog driven command  (Read 15589 times)

0 Members and 1 Guest are viewing this topic.

Glenn R

  • Water Moccasin
  • Posts: 1932
  • What idiot child of married cousins wrote this?!
Re: Windows - Command line and Dialog driven command
« Reply #30 on: October 03, 2008, 02:51:21 AM »
You do, there're just named differently and in the public methods section.
Look for 'op_*' as the name ie op_GreaterThan
Me

T.Willey

  • Needs a day job
  • Posts: 5241
Re: Windows - Command line and Dialog driven command
« Reply #31 on: October 03, 2008, 11:09:33 AM »
You do, there're just named differently and in the public methods section.
Look for 'op_*' as the name ie op_GreaterThan
Thanks for that Glenn.  I wonder how many times I have just passed over those in other classes, and not known what it was.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #32 on: October 03, 2008, 01:58:41 PM »

I had some time to look into 'operator overload', but I didn't how one would know that the class DateTime does overload an operator? 


In an OOP langauge, if a type does not overload an operator, you can't use the operator with instances of the type, and attempting to do so results in a compiler error.

It's more about understanding the fundamental concepts of OOP that allows one to understand that operators must be overloaded by every type they should work with, and that if an operator works for a given type (e.g., no compiler error occurs), then it can and should be used.

Quote

I did notice that DateTime has a Compare method that I should have used. 


Well, you really shouldn't use the Compare method, just as you also shouldn't use string.Equals() where you should be using the == operator.

Using operators makes code more readable. In a development vacume where no other programmer has to look at or work with your code, that may be ok. Otherwise, most seasoned coders will be reluctant to go near code that's poorly written and difficult to read or follow.

Quote

Edit:  All searches so far have shown how to make an overload for a custom class, not how to tell if a class has one.  That is the problem with my searching so far.


As I mentioned above, if a class does not provide an overload for an operator, you can't use it, and a compiler error is generated. So, finding out if a type overloads an operator is as simple as trying to use the operator with an instance of the type, and seeing if an error occurs.


T.Willey

  • Needs a day job
  • Posts: 5241
Re: Windows - Command line and Dialog driven command
« Reply #33 on: October 03, 2008, 02:05:34 PM »
Thanks for the information Tony.  It is very helpful to me.
Tim

I don't want to ' end-up ', I want to ' become '. - Me

Please think about donating if this post helped you.

tjr

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #34 on: October 03, 2008, 08:13:11 PM »
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?
I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: Windows - Command line and Dialog driven command
« Reply #35 on: October 03, 2008, 08:18:53 PM »
For anyone following along, this may be a good place to start reading ;
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

--> Donate to theSwamp<--

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: Windows - Command line and Dialog driven command
« Reply #36 on: October 05, 2008, 12:29:40 AM »
In an OOP langauge, if a type does not overload an operator, you can't use the operator with instances of the type, and attempting to do so results in a compiler error.

It's more about understanding the fundamental concepts of OOP that allows one to understand that operators must be overloaded by every type they should work with, and that if an operator works for a given type (e.g., no compiler error occurs), then it can and should be used.
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

Well, you really shouldn't use the Compare method, just as you also shouldn't use string.Equals() where you should be using the == operator.
And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

Using operators makes code more readable. In a development vacume where no other programmer has to look at or work with your code, that may be ok. Otherwise, most seasoned coders will be reluctant to go near code that's poorly written and difficult to read or follow.
Ouch... maybe you should overload all methods to merely using operators? Or maybe you should learn a language which gets rid of unsightly, difficult to read methods?

As I mentioned above, if a class does not provide an overload for an operator, you can't use it, and a compiler error is generated. So, finding out if a type overloads an operator is as simple as trying to use the operator with an instance of the type, and seeing if an error occurs.
ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.

But what would I know? :)

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 7047
  • AKA Daniel
Re: Windows - Command line and Dialog driven command
« Reply #37 on: October 05, 2008, 12:45:20 AM »
.. In most cases in OOP languages, using == to compare two Strings is absolutely wrong...

This is not correct, in OOP, an object should know how to compare itself to another object of the same type AND provide an operator to do so
I.e  the operator == in .NET, System.String just calls a method Equals

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 7047
  • AKA Daniel
Re: Windows - Command line and Dialog driven command
« Reply #38 on: October 05, 2008, 12:48:47 AM »
Code: [Select]
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

 :-D

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: Windows - Command line and Dialog driven command
« Reply #39 on: October 05, 2008, 12:51:26 AM »
.. In most cases in OOP languages, using == to compare two Strings is absolutely wrong...

This is not correct, in OOP, an object should know how to compare itself to another object of the same type AND provide an operator to do so
I.e  the operator == in .NET, System.String just calls a method Equals

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}

In Java, == tests whether the two strings point at the same object.  You may want to tell Sun that Java isn't OOP :wink:

tjr

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #40 on: October 05, 2008, 01:04:33 AM »
.. In most cases in OOP languages, using == to compare two Strings is absolutely wrong...

This is not correct, in OOP, an object should know how to compare itself to another object of the same type AND provide an operator to do so
I.e  the operator == in .NET, System.String just calls a method Equals

Code: [Select]
public static bool operator ==(string a, string b)
{
    return Equals(a, b);
}

In Java, == tests whether the two strings point at the same object.  You may want to tell Sun that Java isn't OOP :wink:
Same with Python:
Code: [Select]
In [1]: class test(object):
   ...:     def __init__(self, num):
   ...:         self.num = num
   ...:         
   ...:         

In [2]: i = test(2)

In [3]: j = test(2)

In [4]: i == j
Out[4]: False

In [5]: i.num == j.num
Out[5]: True

TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #41 on: October 05, 2008, 01:07:43 AM »
Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?
I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

Hate to disagree. 

Comparing the contents of two files does not tell you which was modified more recently.  The only thing a content based comparison tells you is if the contents of the two files are different, and nothing else.

Keeping in mind that the file's timestamp is meaningful, even if the file's contents are the same, the file that was changed more recently should still be used, so IMHO, there is no point to a content comparison of the files.

TonyT

  • Guest
Re: Windows - Command line and Dialog driven command
« Reply #42 on: October 05, 2008, 01:14:53 AM »
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

In every OOP langauge, there are intrinsic types and user-defined types. Intrinsic types (like numeric types, boolean, and so on) are types the compiler knows about, and knows how to generate code to perform whatever operation a given operator requires.

For user-defined types that are not derived from intrinsic types, or derived from types that provide a virtual member that corresponds to an operator, the compiler *cannot* generate code for a given operator, so it has no choice but to throw an exception.

In the CLR, The == and != operators are the *only* operators that can be used on any type, and that is because all types are derived from System.Object, which provides a virtual Equals() method (overriden by System.ValueType(), System.String, and many others), and that is what the == and != operators delegate to.

In CLR, with == and !=, what happens depends on whether the type being compared is a reference type or a value type. For reference types, the Equals() member of System.Object() returns true if the operands both refer to the same object. 

For value types, System.ValueType() overloads Equals() to perform a byte-by-byte comparison of each object's data.

Hence, in the CLR, == and != are implemented for every object, but any other operator must be overloaded for a given type (or one of its base types), or a compiler error will be generated.

And that's why the compiler must throw an error - because it must generate code for the operator, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

Quote
And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

The reason why one should use operators rather than explicit member functions is quite simple.

There are tens of thousands of classes, and each of them are free to implement functions that correspond to what operators do. The reason why you should use operators is quite simply because you don't have to remember what member function provides the implementation for each and every type. That's the purpose of overloading operators. It allows the programmer to not have to be intimately familiar with a type, and remember what the name of the method that compares two instances for equality, or a relational function like is-greater-than, and so on.

So, for example, you have two types written by two different people and each of them decides that the member function that tells if one instance is greater than another instance, will have two completely different names.

Code: [Select]

public class DumbWidget
{
   public static bool IsLargerThan( DumbWidget first, DumbWidget second )
   {
      // compare instances
   }
  
   public static bool IsSmallerThan( DumbWidget first, DumbWidget second )
   {
      // compare instances
   }
}

public class DumbGadget
{
   public static bool IsTallerThan( DumbGadget first, DumbGadget second )
   {
      // compare instances
   }
  
   public static bool IsShorterThan( DumbGadget first, DumbGadget second )
   {
      // compare instances
   }
}


Notice that the two classes were designed by different people, and each had their own idea about what the relational comparison member functions should be called. There's no protocol for that, there's no requirement or rule that states you must use a certain name, so it's pot luck as to what name will be used.

And this is why you should use overloaded operators:

Code: [Select]

public class SmarterWidget
{
   public static bool IsLargerThan( SmarterWidget first, SmarterWidget second )
   {
      // compare instances
   }
  
   public static bool IsSmallerThan( SmarterWidget first, SmarterWidget second )
   {
      // compare instances
   }
  
   public static bool operator >( SmarterWidget left, SmarterWidget right )
   {
      return IsLargerThan( left, right );
   }
  
   public static bool operator <( SmarterWidget left, SmarterWidget right )
   {
      return IsSmallerThan( left, right );
   }
}


In SmarterWidget, you don't have to remember what the names of the member functions are. You don't need to use intellisense... you only need to use your basic instincts.

It really shouldn't be that difficult to understand that, when types provide overloaded operators that call corresponding member functions (whose name is not the same for every type), the programmer is not required to remember what each type's respective member function is called.

With operators, they don't have to remember anything! They just use the damn operator, and that's that!

Quote

ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.


That's the point... That's not a valid comparison. The class defines the concept of what 'is-greater-than means, not the compiler.

The fact that you believe that the C++ mentality (where '==' generally means "are these two pointers pointing at the same memory address?), should apply to higher-level languages and higher level class abstractions is wrong.

Java's == is also wrong for strings, because the need to tell if two strings refer to the same physical object is rare, in contrast to the need to compare their values lexically. 

Operators should perform the most common comparison, the one that most people would expect it to, and unfortunately that is not what you seem to think most would expect == to do.

Java was written by a C++ programmer, and designed to be friendly to C++ programmers. That was the mistake.

Think of C# as Java with the many of the mistakes corrected.
« Last Edit: October 05, 2008, 03:05:29 AM by TonyT »

It's Alive!

  • BricsCAD
  • Needs a day job
  • Posts: 7047
  • AKA Daniel
Re: Windows - Command line and Dialog driven command
« Reply #43 on: October 05, 2008, 01:15:40 AM »
Ok, Iím kind of wrong here. Value types (structs) should provide an operator for testing equality. Reference type should provide an operator for testing the instance. In .Net a string behaves like a value type

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: Windows - Command line and Dialog driven command
« Reply #44 on: October 05, 2008, 01:24:38 AM »
you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

If the compiler doesn't know how to compare the types, the compiler *will* throw a fit.

What kind of compiler would let you use an operator on a type, if the compiler doesn't know what code it must generate to perform the comparison ?????

Why do you think the compiler throws the error?  It does that because it must generate code for the operation, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

You must be kidding, right?

Sorry.... I think that alone makes any further discussion pointless.

<CADaver>Go back and read what I said</CADaver>

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.  It seems you couldn't be bothered to read the next line where I said that, so I quote it here for you:

And why not use it?  In most cases in OOP languages, using == to compare two Strings is absolutely wrong... in that case you are comparing whether two objects are physically the same object, not whether the two string values are the same things.  Sometimes that may return the correct (read: expected) value, but most of the time you really shouldn't do it.  While that case may not hold true in C#, it is a fallacy to say "In OOP"

 ...

ThisDate > ThatDate doesn't always work in every OOP language, but won't upset the compiler because you are doing a valid comparison.... only not of the values as you would think, but of the objects.

If you're going to basically tell me to shut up, please at least read what I said before... er... re-iterating it to prove I'm wrong? :|