Re: is(this : myClass)
But with the current compiler you would never write
is(typeOf(myC) : typeof(c))
if in your mind "c" is actually a class "C" because if that is
in your mind you would just write
is(typeof(myC) : c)
which would get you the error. You only need typeof(variable)
to get to the type, there is no point in doing typeof(type),
you just write type and C is a type. Right?
But what value is evaluating a class type to a primitive type? It
will never be true? There has to be a reasonable chance for the
evaulation to be true for the 'is' operator to provide value. The
compiler should reject this 'is' statement or at minimum issue a
warning of incompatible types. This is nonsense creep of unusable
code (being able to write code that has no meaning and value).
This is equivalent to writing code like the following. It is just
more obfuscated:
if(false)
{
...
}
else
{
...
}
Patrick
Re: is(this : myClass)
On Friday, 20 October 2017 at 23:24:17 UTC, Patrick wrote:
On Friday, 20 October 2017 at 23:01:25 UTC, Steven
Schveighoffer wrote:
On 10/20/17 6:23 PM, Patrick wrote:
On Friday, 20 October 2017 at 22:15:36 UTC, Steven
Schveighoffer wrote:
On 10/20/17 5:55 PM, Patrick wrote:
Due to the very specific nature of the 'is' operator, why
wouldn't the compiler know to implicitly query the class
types? Why must it be explicitly written, typeof(this)?
The compiler generally doesn't "fix" errors for you, it
tells you there is a problem, and then you have to fix it.
You have to be clear and unambiguous to the compiler.
Otherwise debugging would be hell.
Not asking the compiler to fix my errors.
When would
is(this, myClass) not mean: is(typeof(this) :
typeof(myClass))?
class C
{
}
int c;
C myC;
is(myC : c);
oops, forgot to capitalize. But compiler says "I know, you
really meant is(typeof(myC) : typeof(c)) -> false.
-Steve
If I explicitly wrote: is(typeof(myC) : typeof(c)) the outcome
would still be false and it would still require debugging. So
your example demonstrates nothing other then a type-o was made.
Try again...
In this unique case, the compiler should identify the class and
primitive types are incompatible and should issue an error
instead (and not return false).
Patrick
But with the current compiler you would never write
is(typeOf(myC) : typeof(c))
if in your mind "c" is actually a class "C" because if that is in
your mind you would just write
is(typeof(myC) : c)
which would get you the error. You only need typeof(variable) to
get to the type, there is no point in doing typeof(type), you
just write type and C is a type. Right?
Re: is(this : myClass)
On Friday, 20 October 2017 at 23:01:25 UTC, Steven Schveighoffer
wrote:
On 10/20/17 6:23 PM, Patrick wrote:
On Friday, 20 October 2017 at 22:15:36 UTC, Steven
Schveighoffer wrote:
On 10/20/17 5:55 PM, Patrick wrote:
Due to the very specific nature of the 'is' operator, why
wouldn't the compiler know to implicitly query the class
types? Why must it be explicitly written, typeof(this)?
The compiler generally doesn't "fix" errors for you, it tells
you there is a problem, and then you have to fix it. You have
to be clear and unambiguous to the compiler. Otherwise
debugging would be hell.
Not asking the compiler to fix my errors.
When would
is(this, myClass) not mean: is(typeof(this) : typeof(myClass))?
class C
{
}
int c;
C myC;
is(myC : c);
oops, forgot to capitalize. But compiler says "I know, you
really meant is(typeof(myC) : typeof(c)) -> false.
-Steve
If I explicitly wrote: is(typeof(myC) : typeof(c)) the outcome
would still be false and it would still require debugging. So
your example demonstrates nothing other then a type-o was made.
Try again...
In this unique case, the compiler should identify the class and
primitive types are incompatible and should issue an error
instead (and not return false).
Patrick
Re: is(this : myClass)
On 10/20/17 7:04 PM, user1234 wrote:
Strangely this is not always true, in other contexts this is seen as
atype, although probably a bug
class Foo
{
class Bar : this {}
static assert(is(Bar : Foo));
}
Definitely a bug. You should have to write typeof(this) (which is valid
in this context).
-Steve
Re: is(this : myClass)
On 10/20/17 6:23 PM, Patrick wrote:
On Friday, 20 October 2017 at 22:15:36 UTC, Steven Schveighoffer wrote:
On 10/20/17 5:55 PM, Patrick wrote:
Due to the very specific nature of the 'is' operator, why wouldn't
the compiler know to implicitly query the class types? Why must it be
explicitly written, typeof(this)?
The compiler generally doesn't "fix" errors for you, it tells you
there is a problem, and then you have to fix it. You have to be clear
and unambiguous to the compiler. Otherwise debugging would be hell.
Not asking the compiler to fix my errors.
When would
is(this, myClass) not mean: is(typeof(this) : typeof(myClass))?
class C
{
}
int c;
C myC;
is(myC : c);
oops, forgot to capitalize. But compiler says "I know, you really meant
is(typeof(myC) : typeof(c)) -> false.
-Steve
Re: is(this : myClass)
On Friday, 20 October 2017 at 21:42:32 UTC, Jonathan M Davis
wrote:
On Friday, October 20, 2017 21:32:48 Patrick via
Digitalmars-d-learn wrote:
The compiler seems to reject the following code in a class
method:
bool test = is(this : myClass);
Could some please explain this?
"this" is not a type.
Strangely this is not always true, in other contexts this is seen
as atype, although probably a bug
class Foo
{
class Bar : this {}
static assert(is(Bar : Foo));
}
Re: is(this : myClass)
On Friday, 20 October 2017 at 22:15:36 UTC, Steven Schveighoffer wrote: On 10/20/17 5:55 PM, Patrick wrote: Due to the very specific nature of the 'is' operator, why wouldn't the compiler know to implicitly query the class types? Why must it be explicitly written, typeof(this)? The compiler generally doesn't "fix" errors for you, it tells you there is a problem, and then you have to fix it. You have to be clear and unambiguous to the compiler. Otherwise debugging would be hell. -Steve Not asking the compiler to fix my errors. When would is(this, myClass) not mean: is(typeof(this) : typeof(myClass))? Why would "is(this, myClass)" be ambiguous? What other interpretation would "is(this, myClass)" imply? Patrick
Re: is(this : myClass)
On 10/20/17 5:55 PM, Patrick wrote: Due to the very specific nature of the 'is' operator, why wouldn't the compiler know to implicitly query the class types? Why must it be explicitly written, typeof(this)? The compiler generally doesn't "fix" errors for you, it tells you there is a problem, and then you have to fix it. You have to be clear and unambiguous to the compiler. Otherwise debugging would be hell. -Steve
Re: is(this : myClass)
On Friday, 20 October 2017 at 21:42:32 UTC, Jonathan M Davis wrote: On Friday, October 20, 2017 21:32:48 Patrick via Digitalmars-d-learn wrote: The compiler seems to reject the following code in a class method: bool test = is(this : myClass); Could some please explain this? "this" is not a type. is(T : U) is true if T is implicitly convertible to U. T and U must both be types. So, you need to use the types of this and myClass, even if that's just is(typeof(this) : typeof(myClass)) rather than explicitly using their types. - Jonathan M Davis Thank you. Due to the very specific nature of the 'is' operator, why wouldn't the compiler know to implicitly query the class types? Why must it be explicitly written, typeof(this)? Patrick
Re: is(this : myClass)
On Friday, October 20, 2017 21:32:48 Patrick via Digitalmars-d-learn wrote: > The compiler seems to reject the following code in a class method: > > bool test = is(this : myClass); > > Could some please explain this? "this" is not a type. is(T : U) is true if T is implicitly convertible to U. T and U must both be types. So, you need to use the types of this and myClass, even if that's just is(typeof(this) : typeof(myClass)) rather than explicitly using their types. - Jonathan M Davis
Re: RedBlackTree and myClass
On Sunday, 3 January 2016 at 14:49:59 UTC, tsbockman wrote:
On Sunday, 3 January 2016 at 10:55:05 UTC, AntonSotov wrote:
import std.container.rbtree;
class myClass {
string str;
}
int main()
{
auto tree = new RedBlackTree!myClass;
return 0;
}
Error: mutable method object.Object.opCmp is not callable
using a inout object
Error: template instance std.functional.binaryFun!("a < b",
"a", "b").binaryFun!(inout(myClass), myClass) error
instantiating
/
How to use RedBlackTree of the objects of of its class?
Anyway, it's not too hard if you understand what's going on,
and all of the functions I added are good things to have
anyway, because lots of generic code expects some or all of
them. But, the error messages aren't all that helpful if you
didn't already know most of that.
But as a beginner it is quite disappointing to write all of these
functions to just get it work.
Maybe i am a bad programmer, but i don't write and use the member
functions above that often.
I often use the 'less' in the template arguments to get such
things as comparison done, and implement these functions only if
i have to..
To get it work this should be enough:
import std.container.rbtree;
class myClass {
string str;
override string toString() const {
return "{myClass: " ~ str ~ "}"; }
}
void main()
{
auto tree = new RedBlackTree!(myClass, "a.str < b.str");
}
~ togrue
Re: RedBlackTree and myClass
tsbockman, Many thanks! Now I work for me
Re: RedBlackTree and myClass
On Sunday, January 03, 2016 10:55:05 AntonSotov via Digitalmars-d-learn wrote:
> import std.container.rbtree;
>
> class myClass {
> string str;
> }
>
>
> int main()
> {
> auto tree = new RedBlackTree!myClass;
> return 0;
> }
>
>
> Error: mutable method object.Object.opCmp is not callable using a
> inout object
> Error: template instance std.functional.binaryFun!("a < b", "a",
> "b").binaryFun!(inout(myClass), myClass) error instantiating
> /
>
> How to use RedBlackTree of the objects of of its class?
You either have to define opCmp on your class so that it can be compared
with the < operator, or you need to provide RedBlackTree's constructor a
function to use to compare instead of using <.
- Jonathan M Davis
Re: RedBlackTree and myClass
On Sunday, 3 January 2016 at 10:55:05 UTC, AntonSotov wrote:
import std.container.rbtree;
class myClass {
string str;
}
int main()
{
auto tree = new RedBlackTree!myClass;
return 0;
}
Error: mutable method object.Object.opCmp is not callable using
a inout object
Error: template instance std.functional.binaryFun!("a < b",
"a", "b").binaryFun!(inout(myClass), myClass) error
instantiating
/
How to use RedBlackTree of the objects of of its class?
Internally, `RedBlackTree` needs to be able to compare two
instances of your class. It cannot do so because you haven't
implemented the comparison operators:
http://dlang.org/spec/operatoroverloading.html#eqcmp
It's trying to use the default Object.opCmp() method, but can't
because it doesn't accept constant inputs (`inout` is one of the
many ways to mark something as constant in D:
http://dlang.org/spec/const3.html). You wouldn't want it to use
the default method anyway, since it doesn't understand the
meaning of your class's data fields.
class myClass {
string str;
override string toString() const {
return "{myClass: " ~ str ~ "}"; }
override size_t toHash() const {
return hashOf(str); }
override bool opEquals(Object that) const {
return opEquals(cast(myClass) that); }
bool opEquals(const myClass that) const {
return this.str == that.str; }
int opCmp(const myClass that) const {
if(this.str < that.str)
return -1; // less than
if(this.str > that.str)
return 1; // greater than
return 0; // equal
}
}
Note that all of the new methods are marked `const` on the right.
This is to indicate that they do not mutate (change the value of)
`this` instance when they are called. Similarly, the `const` in
`const myClass that` is a promise by the method not to modify
`that`.
This use of `const` is required to make `RedBlackTree` work,
because it is apparently marking things as `inout` somewhere.
Constant values (of whatever sort) cannot be passed to a function
unless that function promises not to modify them.
It won't compile without the `toString()` either, because
somewhere inside it wants to generate a `string` representation
of a `myClass` instance, probably as part of an exception message.
`toHash()` is not required to make your trivial example work, but
it will be needed if you want to be able to use your class as the
key type for associative arrays:
http://dlang.org/spec/hash-map.html
Anyway, it's not too hard if you understand what's going on, and
all of the functions I added are good things to have anyway,
because lots of generic code expects some or all of them. But,
the error messages aren't all that helpful if you didn't already
know most of that.
Re: RedBlackTree and myClass
On Sunday, 3 January 2016 at 16:25:31 UTC, Tobi G. wrote:
On Sunday, 3 January 2016 at 14:49:59 UTC, tsbockman wrote:
Anyway, it's not too hard if you understand what's going on,
and all of the functions I added are good things to have
anyway, because lots of generic code expects some or all of
them. But, the error messages aren't all that helpful if you
didn't already know most of that.
But as a beginner it is quite disappointing to write all of
these functions to just get it work.
Maybe i am a bad programmer, but i don't write and use the
member functions above that often.
I often use the 'less' in the template arguments to get such
things as comparison done, and implement these functions only
if i have to..
To get it work this should be enough:
import std.container.rbtree;
class myClass {
string str;
override string toString() const {
return "{myClass: " ~ str ~ "}"; }
}
void main()
{
auto tree = new RedBlackTree!(myClass, "a.str < b.str");
}
~ togrue
It just depends on what the class is for.
If it's a private internal data structure which is only used a
few places, then sure - just use the minimum code required to get
the job done.
But, if it's a part of the public API for a module and the class
logically has a natural ordering, it's better to specify its
behavior once in the class definition, rather than re-implement
it everywhere that needs it.
Obviously there isn't much point to creating a class that does
nothing bug wrap `string`, so I tried to provide the generic
solution which can be easily extended to do the right thing when
the class is fleshed out to actually do whatever it is really
supposed to do.
And if you really just want a named `string` wrapper, why not do
this?
class myClass {
string str;
alias str this;
}
Re: RedBlackTree and myClass
On Sunday, 3 January 2016 at 16:44:35 UTC, tsbockman wrote: If it's a private internal data structure which is only used a few places, then sure - just use the minimum code required to get the job done. But, if it's a part of the public API for a module and the class logically has a natural ordering, it's better to specify its behavior once in the class definition, rather than re-implement it everywhere that needs it. Yes. I totally agree with you. In the public API of a module, it can make your life so much easier if it's reuseable in all useful ways.
