Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000764Taste[All Projects] TASTE-IV/DVpublic2018-04-25 07:412021-12-02 10:11
Reportershd01 
Assigned Tomaxime 
PriorityhighSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Summary0000764:

Can't reuse functions due to namespace conflicts

Description

I created a container function, with some functions inside, to use as a generic block for a redundant subsystem. When I import this block into a project for the second time, TASTE renames all the contained functions to default names (e.g. Function6).

This is tedious as I have to rename all the functions by hand to something unique, and then create new behavioural code. I can't have a single source for the implementation.

What I would really like is a clean facility to be able to reuse or duplicate modules, perhaps by creating libraries.

For the time being, I could get by with a hierarchical namespace, i.e. where names are only required to be unique within a function.

I've made this a major severity report as I think it is an impediment to serious use of TASTE in systems modelling.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0003290)
shd01 (reporter)
2018-05-02 09:32

This could be a problem with my understanding. Is it possible to create generic functions that are also containers?

Actually, I am having some trouble creating even a basic generic function (like the ones in Demo_Multi_Instances). What is the correct way to do this?

(0003291)
maxime (administrator)
2018-05-02 11:31

At the moment, the notion of generic functions is still provided as a proof-of-concept prototype. We are addressing it in the current set of updates for TASTE and we will update it step by step based on the needs.

It is so far restricted to individual functions in SDL. One function can be defined as a type, and other as instances of this type. No further refinements on the instance can be made, i.e. we have no inheritance mechanism yet.

The next version of the GUI will ease the creation of types and the instantiation process, as well as the storage in an external library of components (available on the left side, like the PeekPoke component).

Here are a few of the ideas in the roadmad, in order of complexity:

1) Extend to pure Ada and to C++
2) Use context parameters to specify context-dependent constants (set as placeholder in the type with a default value, and actual value in the instances)
3) Use context parameters as they are defined in the SDL standard (i.e. a full template engine / close to Ada generics)
4) Support inheritance / allow overriding the code of PI (ie. OO model from SDL)

and

5) what you introduce: SDL Block/System Type - (Nesting function that is a type and that can be instantiated).
This will be a bit more complicated, but we'll eventually get there.

(0003809)
maxime (administrator)
2021-12-02 10:11

1 and 2 have been implemented


- Issue History
Date Modified Username Field Change
2018-04-25 07:41 shd01 New Issue
2018-04-25 07:41 shd01 Status

new => assigned

2018-04-25 07:41 shd01 Assigned To

=> ellidiss

2018-05-02 09:32 shd01 Note Added: 0003290
2018-05-02 11:31 maxime Note Added: 0003291
2021-12-02 10:11 maxime Note Added: 0003809
2021-12-02 10:11 maxime Assigned To

ellidiss => maxime



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker