Re: std.conv.to
On Friday, 17 June 2022 at 18:40:59 UTC, Ali Çehreli wrote:
On 6/17/22 10:04, Salih Dincer wrote:
> Isn't foo and bar the same thing? I don't understand what's
the
> difference!
> ```d
>auto foo = to!Foo("123"); //??
>auto bar = Foo("321");
> ```
Yes, they are the same thing.
But (!) `to!` inconsiderately smuggled into the code is bubble.
So we will obviously be deceived at a later moment. Thereby
making nonsense further clamour for shorten...:)
Then how did the evolution of the code evolve into the current
form?
```d
auto zar = "123".to!Foo;
auto bar = to!(Foo)("123");
auto foo = to!Foo("123"); // <-- this line is bubble
```
SDB@79
Re: std.conv.to
On 6/17/22 10:04, Salih Dincer wrote:
> Isn't foo and bar the same thing? I don't understand what's the
> difference!
>auto foo = to!Foo("123"); //??
>auto bar = Foo("321");
Yes, they are the same thing.
The OP was looking for a generic way of converting any type to any other
type as long as there is a way. (Think a function template.) std.conv.to
can do that because it considers the constructors as well.
Ali
Re: std.conv.to
On Friday, 17 June 2022 at 12:53:53 UTC, bauss wrote:
Just add a constructor to your type that takes the value of
what you want to convert.
Working example:
```d
struct Foo
{
int value;
this(int v)
{
value = v;
}
this(string v)
{
this(to!int(v));
}
}
void main()
{
auto foo = to!Foo("123");
writeln(foo.value);
}
```
D is full of good surprises. Thanks.
Re: std.conv.to
On Friday, 17 June 2022 at 12:53:53 UTC, bauss wrote:
Just add a constructor to your type that takes the value of
what you want to convert.
Isn't foo and bar the same thing? I don't understand what's the
difference! By the way, what's the question? Is this the answer
to the question?
```d
void main()
{
auto foo = to!Foo("123"); //??
typeid(foo).writeln(": ", foo);
assert("123".to!Foo == foo);
assert(123.to!Foo == foo);
auto bar = Foo("321");
typeid(bar).writeln(": ", bar);
assert("321".to!Foo == bar);
assert(321.to!Foo == bar);
}
```
SDB@79
Re: Need Help with Encapsulation in Python!
[Here](https://www.scaler.com/topics/python/encapsulation-in-python/), they
mentioned a way of simulating encapsulation of class level like this:
```
def private(*values):
def decorator(cls):
class Proxy:
def __init__(self, *args, **kwargs):
self.inst = cls(*args, **kwargs)
def __call__(self, cls, *args, **kwargs):
return self.inst
def __getattr__(self, attr):
if attr in values:
raise AttributeError("Private valueiables are
not accessible!")
else: return getattr(self.inst, attr)
def __setattr__(self, attr, val):
# Allow access inside the class
if attr == 'inst': self.__dict__[attr] = val
elif attr in values:
raise AttributeError("Private valueiables are
not accessible!")
else: setattr(self.inst, attr, val)
def __str__(self):
return self.inst.__str__()
return Proxy
return decorator
```
this can be used for class-level encapsulation (e.g.limiting the
access of a variable or method in a class).
For module-level encapsulation, however, the only way that I can
think of is that you create a file and write the init.py. However
if those who writes the client program knows the structure of
your file / package, this can still not stop them from importing
stuff.
Re: Need Help with Encapsulation in Python!
On Friday, 17 June 2022 at 14:14:57 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 17 June 2022 at 13:58:15 UTC, Soham Mukherjee wrote:
Is there any better way to achieve encapsulation in Python?
Please rectify my code if possible.
One convention is to use "self._fieldname" for protected and
"self.__fieldname" for private class attributes.
Example:
```python
class A:
def __init__(self):
self._x = 3
self.__x = 4
a = A()
print(a.__dict__)
```
will produce the output: ```{'_x': 3, '_A__x': 4}``` .
As you can see the "self.__x" field has the name "_A__x" which
makes it "hidden", but not inaccessible.
But you can use external tools to check for misuse.
Re: Need Help with Encapsulation in Python!
On Friday, 17 June 2022 at 13:58:15 UTC, Soham Mukherjee wrote: Is there any better way to achieve encapsulation in Python? Please rectify my code if possible. One convention is to use "self._fieldname" for protected and "self.__fieldname" for private class attributes.
Need Help with Encapsulation in Python!
```
self.a = 1
self.b = 2
self.c = 3
pass
def __getattribute__(self, name):
if sys._getframe(1).f_code.co_argcount == 0:
if name in self.privates:
raise Exception("Access to private attribute \"%s\" is
not allowed" % name)
else:
return object.__getattribute__(self, name)
else:
return object.__getattribute__(self, name)
def __setattr__(self, name, value):
if sys._getframe(1).f_code.co_argcount == 0:
if name in self.privates:
raise Exception("Setting private attribute \"%s\" is not
allowed" % name)
elif name in self.protected:
raise Exception("Setting protected attribute \"%s\" is
not allowed" % name)
else:
return object.__setattr__(self, name, value)
else:
return object.__setattr__(self, name, value)
example = EncapsulationClass()
example.a = 10 # Exception: Setting private attribute "a" is not
allowed
example.b = 10 # Exception: Setting protected attribute "b" is
not allowed
example.c = 10 # example.c == 10
example.__dict__["privates"] # Exception: Setting protected
attribute "b" is not allowed
```
What would actually be wrong with doing something like this?
Is there any better way to achieve encapsulation in Python?
Please rectify my code if possible.
Re: nested function overloading
On Friday, 17 June 2022 at 13:04:47 UTC, Chris Katko wrote: On Friday, 17 June 2022 at 12:19:33 UTC, bauss wrote: On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote: I don't need this functionality, but I wanted to be sure. Does function overloading not work with nested functions? I got a compiler error (something like "function already defined") when I tried it. According to the spec then nested functions cannot be overloaded: "Nested functions cannot be overloaded." See: 19.17.1.3 https://dlang.org/spec/function.html#nested Thanks! re: documentation. That is one-line tiny footnote in a page that's over 85 pages long on my browser. :) I could easily see many people missing it until they encounter it. I agree, I didn't know about it either and only found out because I decided to search on the page for functions under nested functions.
Re: nested function overloading
On Friday, 17 June 2022 at 12:19:33 UTC, bauss wrote: On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote: I don't need this functionality, but I wanted to be sure. Does function overloading not work with nested functions? I got a compiler error (something like "function already defined") when I tried it. According to the spec then nested functions cannot be overloaded: "Nested functions cannot be overloaded." See: 19.17.1.3 https://dlang.org/spec/function.html#nested Thanks! re: documentation. That is one-line tiny footnote in a page that's over 85 pages long on my browser. :) I could easily see many people missing it until they encounter it.
Re: std.conv.to
On Friday, 17 June 2022 at 12:48:56 UTC, harakim wrote:
On Friday, 17 June 2022 at 12:31:45 UTC, harakim wrote:
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
return read!int(val => to!int(val), "number");
}
string readTime()
{
return read!string(val => toTime(val), "time");
}
private T read(T)(T function(string) transform, string
typeName)
{
string input = readln();
return transform(input);
}
```
However, I want to be able to convert my own custom types as
well. How do I do that? Is there an operator overload I need
to override for that? Do I have to static if on the template
type and call the object?
I have no idea why I was stuck on this problem for so long. I
can specify anything I want in the transform and I even do in
my own example lol. I am still curious if there is a way to
make your type work with to!MyCustomType(source)
Just add a constructor to your type that takes the value of what
you want to convert.
Working example:
```d
struct Foo
{
int value;
this(int v)
{
value = v;
}
this(string v)
{
this(to!int(v));
}
}
void main()
{
auto foo = to!Foo("123");
writeln(foo.value);
}
```
Re: std.conv.to
On Friday, 17 June 2022 at 12:31:45 UTC, harakim wrote:
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
return read!int(val => to!int(val), "number");
}
string readTime()
{
return read!string(val => toTime(val), "time");
}
private T read(T)(T function(string) transform, string
typeName)
{
string input = readln();
return transform(input);
}
```
However, I want to be able to convert my own custom types as
well. How do I do that? Is there an operator overload I need to
override for that? Do I have to static if on the template type
and call the object?
I have no idea why I was stuck on this problem for so long. I can
specify anything I want in the transform and I even do in my own
example lol. I am still curious if there is a way to make your
type work with to!MyCustomType(source)
std.conv.to
I can generically convert a string to a type using to!type. I
have a read function that does that. I have simplified the
example below:
```d
int readNumber()
{
return read!int(val => to!int(val), "number");
}
string readTime()
{
return read!string(val => toTime(val), "time");
}
private T read(T)(T function(string) transform, string typeName)
{
string input = readln();
return transform(input);
}
```
However, I want to be able to convert my own custom types as
well. How do I do that? Is there an operator overload I need to
override for that? Do I have to static if on the template type
and call the object?
Re: UFCS limit
On Friday, 17 June 2022 at 12:26:05 UTC, Antonio wrote: UFCS vs Functional curring... nice battle :-) **UFCS & CFTE** vs **Functional currying**... nice battle :-)
Re: UFCS limit
On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:
On Thursday, 16 June 2022 at 23:59:06 UTC, Antonio wrote:
Is it there any way to apply UFCS on the returned method in
the same expression?
Nope. The way UFCS works is that allows you to call free
functions using member-function syntax, and member-function
syntax is always `object.memberName`, so UFCS only works for
functions that have a name, not anonymous functions.
Lets tray with a name :-)
```d
auto doSomething(string text)
{
return (string text2)
{
import std.stdio;
writeln(text,",",text2);
};
}
void main()
{
auto doHello = doSomething("Hello");
doHello("X");
"X".doHello();
}
```
Error: onlineapp.d(16): Error: no property `doHello` for type
`string`
It's true... the favomous "Rationale: Local function symbols are
not considered by UFCS to avoid unexpected name conflicts." (I
consider it absurd... but I'n no-one)
Well lets try another possibility taking in account the power of
CTFE
```d
auto doSomething(string text)
{
return (string text2)
{
import std.stdio;
writeln(text,",",text2);
};
}
auto doHello = doSomething("Hello");
void main()
{
doHello("X");
"X".doHello();
}
```
Error: onlineapp.d(3): Error: closures are not yet supported in
CTFE
:-/
UFCS vs Functional curring... nice battle :-)
Re: nested function overloading
On Friday, 17 June 2022 at 12:09:33 UTC, Chris Katko wrote: I don't need this functionality, but I wanted to be sure. Does function overloading not work with nested functions? I got a compiler error (something like "function already defined") when I tried it. According to the spec then nested functions cannot be overloaded: "Nested functions cannot be overloaded." See: 19.17.1.3 https://dlang.org/spec/function.html#nested
nested function overloading
I don't need this functionality, but I wanted to be sure. Does function overloading not work with nested functions? I got a compiler error (something like "function already defined") when I tried it.
Re: UFCS limit
On Friday, 17 June 2022 at 05:17:20 UTC, Tejas wrote: On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote: Nope. The way UFCS works is that allows you to call free functions using member-function syntax, and member-function syntax is always `object.memberName`, so UFCS only works for functions that have a name, not anonymous functions. Would it be worthwhile to extend the scope of UFCS to accomodate this use case as well though?? I think it would lead to a lot of confusing and ambiguity.
