Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Hello, everyone! We, at UPB, have initiated D's participation to ROSEdu Summer Awsome! Come to Titu Maiorescu University too. Here, we love D, some of us at least. :)
Re: Sealed classes - would you want them in D? (v2)
On Monday, 21 May 2018 at 15:07:39 UTC, KingJoffrey wrote: My suggestions are about resolving this, in order to attract more programmers to D, because I doubt I'm the only person in the world, that believes an object has a right to privacy. Of course you are not the only person that believes that. To have full private access in module scope is like you live in a building and there are no walls between apartments.
Re: Override member variables
On Sunday, 20 May 2018 at 03:02:28 UTC, KingJoffrey wrote:
On Saturday, 19 May 2018 at 18:09:56 UTC, Gheorghe Gabriel
wrote:
And of course, you cannot override private members.
wtf!
what do you mean we cannot override private members!
I mean:
module base;
class Base {
protected int x = 1;
private int y = 2;
}
module a;
class A : Base {
override int x = 7;
override int y = 12; // error: y is not accessible
}
Override member variables
I've worked with a lot of programming languages and I've found
something interesting in Kotlin. You can override member
variables. Would you like to have this feature in D?
class Rectangle {
int width = 0;
int height = 0;
}
class Table : Rectangle {
override int width = 10;
override int height = 14;
}
In my opinion it's a more cleaner sintax and you don't need to
put them in constructors. When you look at the Table class
definition/documentation you see that it changes width and height
and their new default values. I am curious about your opinions. :)
And of course, you cannot override private members.
Re: Sealed classes - would you want them in D? (v2)
On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
Mmm.. that brings me back to the idea of sealed at the class
level again.
class A
{
private int x;
private(this) int y; // imagine if you have lots of private
variables.
// this could become pretty anoying -
and kinda redundant.
}
class A
{
private int x;
sealed int y; // again, what if you have lots of private
variables that
// that you really want sealed.
}
// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) ..
confusion.
//
sealed class A{
private int x;
private int y;
}
downside, is adding a new keyword, and getting agreement on
what that new keyword should be.
So I've come full circle again, and believe my idea is worth
further consideration.
If you have
sealed class A {
private {
// members
}
}
Then you can't use the defualt 'private' if you need it for a
specific member.
But if sealed is an access type of a member, 99% you will use
sealed insted private in a class, so it is not redundant.
class A {
sealed {
// members
}
private int friendMember;
}
And you use private keyword only if you need to access that
variable from a class/function/struct.. in the same module, like
a friend.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote: On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote: [...] This is simply unavoidable - and, that 'surprise' you mention, is already there - it's not dependent on, or in any way related, to any proposal that might result from this discussion. The D 'private is really public in a module' concept, is here to stay (sadly, but it's true). [...] C++ is a complex beast, as a result of both needing to accomodate change (evolve), and not wanting to break backwards compatability. It's still *the* most powerful and flexible tool available for programmers. Beginner programmers would do well to keep that in mind. A class is just an abstract type, a tool for those that think it is useful in the solution for their problem domain. In any case, this discussion is not about convincing you of the value of classes - you should already know that if you are programmer. This discussion (at least my reason for being involved in it) is about breaking this idiotic (in my opinion) concept that D enforces on 'everyone' - i.e the one class per module, or everything is public, and you have no say in it. I don't necessarily object to the freedom the D module provides (i.e to bypass your interfaces, even accidently). What I object to is the 'i.e the one class per module, or everything is public, and you have no say in it.' A proposal that empowers the programmer to use the module for more than just a container for single class, coupled with static compile time verification - i.e you can't accidently access your private(this) T as it would be a compile time error, would be good for D (in my opinion), because those that have enjoyed having this capability in other mainstream langauges for literally decades!, won't be shut out from using D. It will attract more programmers, not less - and trust me, D better get more programmers using it, cause 18 years on, and it hasn't got that far, really. To get more programmers, you might want to be more open to accomodating their needs too. Although I do wonder, sometimes, whether the aim if D is just to be this cosy little langauge that not many use, except for those that do. Sometimes, I really need to put 2-3 or more different classes in a module and I don't want them to share private members (friend classes). The current solution is to create an individual module for each class, but I don't like it when my class logic-strucrure fits better in the same module. A better solution could be private(this). I am sure that D really needs something like this. I have been talking with my friend programmers for 4 hours and they don't like the fact that D classes couldn't protect thier members in the same module. So they stuck on java and c#..
Re: Sealed classes - would you want them in D? (v2)
On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:
On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
[...]
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
You may not need a new word at all. You can also enhance
private to take arguments. Package already does this. You can
give private a symbol list that says which symbols this is
private for. So:
class A {
private int x;
private(A) int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Cheers,
- Ali
Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin for
multiple classes.
Example:
string var = "private(this) var;";
class A {
mixin(var);
}
class B {
mixin(var);
}
Re: Sealed classes - would you want them in D? (v2)
On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even
better ;-)
Add an new attribute to class, named 'sealed'.
No, not sealed as in Scala.
No, not sealed as in C#
sealed as in oxford dictionary (close securely, non-porous).
when sealed is applied on the class, this means the class is
sealed.
the sealed attribute only makes sense within a module, and
affects nothing outside of the module.
When sealed is applied to the class, then, interfacing to a
class within a module, from code outside that class - but still
within the module, can now only occur via the published
interface of the class.
outside code in the module, can no longer directly access your
private parts!
The class is sealed.
I think this code has cleaner sintax:
class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}
Re: Binderoo additional language support?
On Sunday, 6 May 2018 at 15:28:11 UTC, Ethan wrote: https://goo.gl/forms/DtKpuwOWR9V2TCnP2 Rapidly iterating my D code from C++ or .NET is great, but these are only two use cases that I know of. So. Let's see what other use cases are out there, and what are the most common ones. The link above goes to a Google Form where you can answer a bunch of questions that will give me an idea of what other languages I should account for. It doesn't require you to sign in, so all data is anonymous (to me anyway). There's only six multiple choice questions, so if you have a minute go head and fill it out. Cheers. Done! :)
Re: I need runtime reflection
On Saturday, 30 September 2017 at 19:06:20 UTC, bitwise wrote: On Friday, 29 September 2017 at 16:40:38 UTC, Gheorghe Gabriel wrote: [...] Still work to do, but usable. https://github.com/nicolasjinchereau/d-reflection I understand, thank you! :) I have created another scripting model (compiled, not interpreted) for the graphics engine, which is better than the runtime reflection (it has only one disadvantage and more advantages over it). I cannot wait until the engine is finished, so that I will be able to show it to the public. Gabriel
Re: I need runtime reflection
On Friday, 29 September 2017 at 16:24:32 UTC, bitwise wrote: On Friday, 29 September 2017 at 11:05:00 UTC, Gheorghe Gabriel wrote: [...] If i compile this script to a .dll DLL support for D is currently very spotty. Before investing too much time, I would suggest confirming that DLLs are even properly supported for your target platform at all. So, could you upload a copy of your own reflection module? I want to try it and then I will send you my feedback.
Re: I need runtime reflection
On Friday, 29 September 2017 at 09:34:26 UTC, JN wrote:
On Wednesday, 27 September 2017 at 20:03:27 UTC, Gheorghe
Gabriel wrote:
Hi,
I have a 3D scene editor.
I need my scripts to be dynamically loaded in the scene.
In c# or java I can use reflections to do that.
How can I do that with D?
I know that std.traits only works in compile time.
Please, help me
Gabriel
Your best bet is to either use a scripting language like Lua
(Unity is written in C++ and uses C#), or compile your scripts
to a dll and load them from there.
Thank you for your answer,
This is a script example:
module game.player;
import engine;
class Player : Actor {
this(string name) {
super(name)
}
~this() {}
void jump() { ... }
@Editable("Slider")("min = 0; max = 5;")
ubyte lives = 5;
}
If i compile this script to a .dll then pleyer object can be
dragged and dropped into the scene?
Do yout think that after the final LDC Android build, the game
will work properly on Android? (because of .dll scripts)
Gabriel
Re: std.reflection prototype
On Thursday, 28 September 2017 at 01:33:35 UTC, bitwise wrote:
On Wednesday, 27 September 2017 at 20:38:51 UTC, Gheorghe
Gabriel wrote:
On Monday, 30 March 2015 at 01:11:55 UTC, bitwise wrote:
[...]
Hi, your link is not working any more and I really need your
implementation.
Gabriel
I took the code down because there were design flaws I had to
work out. I've reworked the code significantly at this point. I
can throw a copy up on github in a day or two if you need it.
There are still some issues to overcome though, which may or
may not be a problem depending on what you're doing.
Thank you, I really need it for my project.
I want to load scripts in a 3D scene without compiling an
restarting the whole engine.
example:
module game1.player;
class Player : Actor {
this(string name) {
super(name)
}
~this() {}
void jump() { ... }
@Editable("Slider")("min = 0; max = 5;")
ushort lives = 5;
}
In this moment I want to load this script and create a scene
object.
I should load Player class, then all its public methods, then its
public members and check theire attributes.
Re: std.reflection prototype
On Monday, 30 March 2015 at 01:11:55 UTC, bitwise wrote:
I came across this post a while back and decided to implement
it:
http://forum.dlang.org/thread/juf7sk$16rl$1...@digitalmars.com
My implementation:
https://github.com/bitwise-github/D-Reflection
The above conversation seemed to stop abruptly, so I went on to
assume that no one chose to champion the task.
At the time, I looked around for other conversations or
attempts at runtime reflection for D, but couldn't really find
anything. I did find the ModuleInfo/reflection stuff in
object.d, but it seemed like an effort that may have been
abandoned. Also, the above conversation seemed to suggest it
should be opt-in, which also made me wonder if the stuff in
object.d was abandoned or for a different purpose.
Looking again today, someone seems to have been working on it a
bit.. For example, MemberInfo_field and MemberInfo_function
were empty last time I checked.
So what's the current state of things?
Is anybody working on it?
Although MemberInfo_field exists, it doesn't seem to be
available from TypeInfo_Class... Is that the eventual goal?
Is there anything I can do to help get things moving?
Any comments on my implementation would be welcome as well.
(https://github.com/bitwise-github/D-Reflection)
main.d shows some general use cases, but basically, if the
reflect(T) template is used on a class,
that class, and any child types will be reflected. Recursive
reflection only propagates downward, or else it could leak
sideways and unnecessarily reflect several modules.
Most of the reflection information is available at compile
time. For example:
enum name =
reflectModule!(test).findClass("Test").findField("variable").name;
pragma(msg, name); // "variable" will be outputted.
To make a module available for runtime reflection, the
following can be used:
mixin(runtimeReflection!test);
At this point, the above example can be rewritten as:
string name =
getModuleReflection("tests.test").findClass("Test3").findField("static_variable").name;
writeln(name);
Hi, your link is not working any more and I really need your
implementation.
Gabriel
I need runtime reflection
Hi, I have a 3D scene editor. I need my scripts to be dynamically loaded in the scene. In c# or java I can use reflections to do that. How can I do that with D? I know that std.traits only works in compile time. Please, help me Gabriel
