Hi Jake,

We're currently in the process of shifting our class constructor story 
to what is described in the following document:

https://github.com/chapel-lang/chapel/blob/master/doc/chips/10.rst

We expect support of this style of constructor to be very prototypically 
available in the upcoming release, though probably wouldn't recommend 
that users start writing in this style until the 1.15 release unless 
they are very, very careful.  In particular, many of the requirements 
placed on the stricter portion of the body will not be strongly 
enforced, and we don't foresee generics being supported until that 
time.  But our current support will remain available throughout this 
process, for what it's worth.

I'm not quite sure I understand what you're encountering with your 
constructors - can you send an example code of what is causing problems?

Setting your fields to default values is a safe way to handle defaults 
in classes.

Our class constructors ought to be sufficient for most operations, 
though we are aware of cases for which the current implementation is 
unsuited (hence the move towards a more robust implementation).  I think 
it is likely that the current story can handle what you are looking for, 
but am uncertain how to guide you without a little more information on 
the situations that are causing you difficulty.  Unfortunately I'm not 
finding a recent tutorial that focused on classes with enough depth to 
be a good guide, but I may be missing something.

Thanks,
Lydia


On 09/04/2016 07:25 PM, Caswell, Jacob wrote:
> Hi Brad and Lydia,
>
> Thank you so much for your response. That all makes a lot of sense.
>
> How far along is the Class constructor story? Also, are there any documents 
> regarding Chapel's goals for OO, or any best practices? For instance, I can't 
> seem to create default constructors (the compiler always asks for a generic 
> argument for the class' variables). Instead, I've been setting my fields to 
> default values. Is this a safe way to handle defaults in classes in Chapel?
>
> I'm also getting some "unresolved call" to non-default constructors. Is there 
> presently a way (without using specific methods within the class) for setting 
> class variables to new values using a constructor? This is using the 
> chapel-1.13.1, for the record. I can try to use an updated master branch, if 
> it helps.
>
> Thank you very much,
> Jake
> ________________________________________
> From: Brad Chamberlain <[email protected]>
> Sent: Monday, August 29, 2016 4:42 PM
> To: Caswell, Jacob
> Cc: Chapel Users Mailing List
> Subject: Re: [EXTERNAL] Nested classes in Chapel
>
> Just to follow up slightly on Lydia's mail, I wanted to note:
>
> * nested classes haven't been a significant feature area for us to work
>     on over the project's history due to the sense that we have bigger
>     fish to fry -- both in general (e.g., parallelism, distributed memory
>     support, performance), and in terms of the OOP features (e.g., fixing
>     our constructor story).
>
> * we'd be very interested in input from users on the importance of
>     nested classes or "better" ways to do them in Chapel if you think we're
>     headed into a bad place.
>
> * generally, when we say "similar to classes in Java", this should be
>     interpreted in a very general sense (e.g., "as opposed to classes in
>     C++") rather than a statement that our goal is to support the same
>     feature set as Java and/or in the same way.
>
> -Brad
>
>
>
> On Mon, 29 Aug 2016, Lydia Duncan wrote:
>
>> Hi Jake,
>>
>> I don't think it is possible to create an instance of the inner class type
>> from outside of the outer class.  I believe we don't allow those symbols to
>> be referenced outside of the scope of the outer class - this is similar to
>> how we treat nested functions. However, you can get an instance of the inner
>> class to live outside of the outer class by having the outer class return an
>> instance and storing that result, and you can call methods on the inner
>> class.
>>
>> Unfortunately a quick check through our most likely test directory didn't
>> reveal an exact candidate matching this scenario.  The closest I could find
>> is this future (read: test that doesn't quite work today) example,
>> https://github.com/chapel-lang/chapel/blob/master/test/classes/vass/nested-class-with-user-defined-constructor-1.chpl
>>
>> A simple modification to this program will cause it to behave "properly" or
>> close to your purpose - merely add an "outer" arg to the inner constructor,
>> or remove the user-defined inner constructor entirely.
>>
>> That program stores an instance of the inner class, but it uses a method on
>> the outer class to generate it, so that the inner class always knows what
>> outer instance it points to.  Note that if you try to declare the type of
>> "i", you get a type resolution failure.
>>
>> Hope that helps,
>> Lydia Duncan
>>
>> On 08/28/2016 10:09 AM, Caswell, Jacob wrote:
>>> My apologies, I found the answer to the access question in the language
>>> specification. However, I couldn't find an example for creating an instance
>>> of an inner class outside of the outside class. Is it called just as:
>>>
>>>
>>> class outside {
>>>
>>>      ...
>>>
>>>      class inside {
>>>
>>>          ...
>>>
>>>      }
>>>
>>> }
>>>
>>>
>>> var out_class : outside;
>>>
>>> var in_class : outside.inside;
>>>
>>>
>>> Or is there another form of declaration and initialization?
>>>
>>>
>>> Thank you very much,
>>>
>>> Jake
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Caswell, Jacob <[email protected]>
>>> *Sent:* Sunday, August 28, 2016 10:36 AM
>>> *To:* [email protected]
>>> *Subject:* [EXTERNAL] Nested classes in Chapel
>>>
>>> Hello all,
>>>
>>>
>>> I found the following tutorial that says classes in Chapel are similar to
>>> classes in Java. Does this mean that Chapel supports nested classes as
>>> well? I've been reworking some of my code to use object oriented structures
>>> to help facilitate task parallelism in a multilocale execution. The idea
>>> being that I could create an instance of the task, which needs both fields
>>> and methods specific to the executing locale, in a reusable way. However,
>>> I've been having some issues with using nested classes in my code.
>>>
>>>
>>> In Chapel, is it possible to create an instance of an inner class, either
>>> within a method from the outer class or outside of both of the classes? And
>>> if so, what access will the inner class have? Can it return variables from
>>> its outer class? Is there documentation for this functionality that I
>>> missed?
>>>
>>>
>>> Thank you very much,
>>>
>>> Jake
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Chapel-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/chapel-users
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Chapel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-users


------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users

Reply via email to