On 2016-07-30 11:26, Lodovico Giaretta wrote:

> I'm proud to announce that std.experimental.xml v0.1.0 is available on
> DUB [1]!
>
> This is the project I'm working on for GSoC 2016. It aims to become a
> substitution for Phobos std.xml. Now you can easily try it and provide
> some feedback. I will soon create a WIP PR on the Phobos repository.

* Does it work at CTFE?
* I see that it doesn't follow the D naming conventions

-- 
/Jacob Carlborg

On Sunday, 31 July 2016 at 12:04:18 UTC, Steven Schveighoffer wrote:

> 2) The function "exit", I don't like. This is bikeshedding, but I just don't like the possibility that to conflate with C exit. I don't have a good replacement name for enter/exit, so this comment is pretty minor.
>
> -Steve

How about `leave` (enter/leave)

On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote:
> * Does it work at CTFE?
I don't think so.

> * I see that it doesn't follow the D naming conventions
You are talking about upper/lower cases in the names, right? I will correct them in the Phobos PR.

On 2016-08-03 09:20, Lodovico Giaretta wrote:
> On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote:
>> * Does it work at CTFE?
> I don't think so.

It would be cool if it did. I think it would at least be worth taking a couple of minutes and investigate if it does work or not. If doesn't work, what it would take to make it work.

Most parts in D work at CTFE but there are some particular things that are not compatible like allocating with malloc instead of the GC. I see that allocators are used, not sure how well those work at CTFE. At least in theory the GC allocator should work.

> You are talking about upper/lower cases in the names, right? I will
> correct them in the Phobos PR.

Yes, and some methods use Java style getters and setters, instead of D style properties. Example:

// Java style
int getFoo();
void setFoo(int foo);

// D style
int foo();
int foo(int foo);

In D, the above can be called like:

Bar bar;
auto i = bar.foo;
bar.foo = 3;

-- 
/Jacob Carlborg

On 2016-07-30 11:26, Lodovico Giaretta wrote:
> Hi,
>
> I'm proud to announce that std.experimental.xml v0.1.0 is available on
> DUB [1]!

Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type.

-- 
/Jacob Carlborg

On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote:
> Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type.

Well, currently you have to make that choice as developer, and there is always the BufferedLexer which should be good choice is most cases. Polymorphic design was not a goal of the project, so I think it is going to be hard to add that without sacrificing to much.

On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote:
> On 2016-07-30 11:26, Lodovico Giaretta wrote:
>> Hi,
>>
>> I'm proud to announce that std.experimental.xml v0.1.0 is available on
>> DUB [1]!
>
> Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type.

I don't know if it is what you want, but you can do this:

auto lexer = chooseLexer!input;

The function chooseLexer creates the most suitable lexer type based on the input type.

You can test if a type is a lexer using the trait isLexer defined in std.experimental.interfaces.

On 2016-08-03 22:57, Robert burner Schadek wrote:

> Well, currently you have to make that choice as developer, and there is
> always the BufferedLexer which should be good choice is most cases.
> Polymorphic design was not a goal of the project, so I think it is going
> to be hard to add that without sacrificing to much.

I'm not talking about a polymorphic design. I'm talking about how most functions work with ranges. They adapt depending on what type the input range is. Example, there's one lexer for forward ranges and one for input ranges. Why is that necessary? It's not necessary for functions in std.algorithm to use different names for a function for different input types.

-- 
/Jacob Carlborg

On 2016-08-04 09:15, Lodovico Giaretta wrote:

> I don't know if it is what you want, but you can do this:
>
> auto lexer = chooseLexer!input;
>
> The function chooseLexer creates the most suitable lexer type based on
> the input type.
>
> You can test if a type is a lexer using the trait isLexer defined in
> std.experimental.interfaces.

Please see my reply to Robert [1].

[1] http://forum.dlang.org/post/nnv6gt$sbe$1@digitalmars.com

-- 
/Jacob Carlborg